[HN Gopher] IronRDP: a Rust implementation of Microsoft's RDP pr...
___________________________________________________________________
IronRDP: a Rust implementation of Microsoft's RDP protocol
Author : mikece
Score : 314 points
Date : 2025-03-21 15:35 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| geenat wrote:
| Does this implement a server? or client only? Linux?
| jeroenhd wrote:
| This code seems to be part of some kind of cloud offering for
| enterprise cloud environments. A lot of RDP code seems to
| concentrate on a React component for connecting to an RDP
| server.
|
| Edit: I've juist built the code on Linux and the demo video is
| recorded on Windows, so this seems multi-platform. There's also
| code for a .NET client in Avalonia (a cross-platform GUI
| library) so I'm guessing the entire thing should work on any
| modern OS.
|
| There's a basic skeleton for an RDP server in the code, but the
| README is a bit short.
| hulitu wrote:
| > React component
|
| > code for a .NET client in Avalonia
|
| So is this written in Rust or not ?
| steveklabnik wrote:
| Github's languages analysis says 87.7% Rust, 9.3% C#, 1.3%
| TypeScript.
| awakecoding wrote:
| Yes, IronRDP is written entirely in Rust, but we also have
| bindings for .NET and the web. We originally developed it
| for our RDP web client for Devolutions Gateway
| (https://github.com/Devolutions/devolutions-gateway) but
| now also support it as an option in Remote Desktop Manager
| (https://devolutions.net/remote-desktop-manager/).
|
| Devolutions Gateway implements the RDCleanPath extension
| used to bridge WSS to RDP, making the connection from a web
| client possible. The same IronRDP core can be compiled to a
| native client for regular RDP connections outside the
| browser. There is also some work done for the server, but
| it's not as advanced as XRDP.
| jeroenhd wrote:
| The demo in the README is pretty impressive for an independent
| implementation, but I also noticed the repo includes server code
| (https://github.com/Devolutions/IronRDP/tree/master/crates/ir...)
| . I wonder if tools like Proxmox could use this as a more
| efficient alternative to VNC (which is slow and weird) or SPICE
| (for which there are very few non-Linux tools).
| rcarmo wrote:
| And it is superbly performant if you use xorgxrdp-glamor for
| rendering and openh264 for transport.
| Nextgrid wrote:
| Part of what makes RDP performant compared to VNC is that the
| RDP server is aware of the GUI state and a lot of compositing
| is actually done by the client.
|
| A hypervisor just sees the video output from the VM and has no
| knowledge of the underlying GUI's state, so even with RDP it
| won't be able to do much better than stream compressed bitmaps.
| generalizations wrote:
| Seems like what we need is a specialized compression
| algorithm. Since the domain is largely constrained it sure
| seems like there's some low-hanging fruit here.
| nix0n wrote:
| VNC with compression does already exist in the form of
| TightVNC[0].
|
| [0]https://en.wikipedia.org/wiki/TightVNC#Encodings
| nemanja wrote:
| Lots of tradeoffs. If you invent a new codec, it's unlikely
| to make it into hardware for a while (even AV1 encoders are
| not yet as widely supported) and therefore you will have to
| do encoding and even decoding in CPU, which takes away
| resources from the workload. h.264 is still probably the
| best general purpose codec for real-time desktop streaming
| - low bandwidth requirements, 444 support, build to
| lossless, low latency, moderate CPU usage if GPU is not
| available, and well supported in GPUs for a long time (e.g.
| even back to Kepler).
| jeroenhd wrote:
| True, but that also goes for VNC (though VNC isn't as
| optimised as RDP is).
|
| Modern RDP also has the option to turn (parts of) the screen
| into a simple h.264 stream so the connection doesn't die when
| you open up a web page with an animated background.
| nemanja wrote:
| RDP is aimed at a different use case than VNC. Proxmox and
| other virtualization managers (e.g. VMWare, Nutanix) use VNC
| because you get a stream directly from the hypervisor (e.g.
| KVM, ESX) which is very useful for low-level debugging. The VNC
| protocol also has very low overhead (you don't really want h264
| encoding CPU overhead on your VM host). VNC is not really
| intended for remote desktop use cases, which require higher
| fidelity/frame rate, etc.
|
| So -
|
| * VNC: Low overhead / Low fidelity
|
| * RDP (and other remote desktop protocols, e.g. Frame Remoting
| Protocol, Horizon Blast, Citrix ICA/HDX): Higher overhead /
| High fidelity
| TheRealPomax wrote:
| Also note that there is a _critical_ difference in how they
| talk to the OS:
|
| * VNC (and other non-RDP solutions like TeamViewer etc):
| fully independent application, does not change how Windows
| works because it's effectively just an interactive screen
| recorder running for your user account.
|
| * RDP: is an actual Windows remote user session that hijacks
| the computer (so a local user can't see what's happening) and
| hooks directly into Windows with its own device bindings and
| login properties (e.g, you can't just click start -> shut
| down, instead you need to command-line your way to victory).
|
| If you want to remote into a machine that's playing audio
| without interfering with that, RDP is flat out not an option.
| Even if you pick "leave audio on the remote", the fact that
| RPD forces windows to use a different audio _device_ is
| enough to interfere with playback.
| jeroenhd wrote:
| RDP doesn't need to tie into the OS like that. Plenty of
| ways to run X11 over RDP, for instance. And unlike in VNC,
| you can actually use the forward/back buttons on your
| mouse!
|
| RDP _in Windows_ happens to be implemented using some fancy
| tricks that make it a much better OS for remote work than
| any Linux distro, but that doesn 't mean that's the only
| possible implementation. Whatever logic can be used to
| detect block updates in VNC works just as well over RDP.
| Audio over RDP also works fine on both Windows and Linux so
| I don't see what the problem would be anywhere else.
|
| As for the shutdown thing, Linux seems to do that too.
| Makes sense if you use your computer as a terminal server,
| I guess. I don't reboot my computer over RDP enough to
| care, really. Still, that's just an implementation choice,
| nothing to do with the protocol itself.
| p_ing wrote:
| What qualifies as "low" overhead?
|
| RDP will run without issue over a 56k modem in a low color
| mode to an RDP Host.
| nemanja wrote:
| Low CPU overhead. VNC streams screen grabs with minimal (if
| any) compression, which results in lower CPU overhead, high
| bandwidth consumption and low frame rate. This is okay for
| the use-case of low-level VM debugging that it's used for
| in context of virtualization management systems, not so
| great for desktop remoting.
|
| While RDP may run okay on 56k with low color mode for some
| use cases (e.g. simple Windows admin), it requires
| significantly more bandwidth and compute overhead (either
| CPU or GPU) for other more advanced use-cases (e.g. video
| editing, CAD etc.)
| andrewf wrote:
| That might practically be where VNC finds usage today, but
| when it was introduced in the 90s, remote desktops were the
| intended use case.
|
| "In the virtual network computing (VNC) system, server
| machines supply not only applications and data but also an
| entire desktop environment that can be accessed from any
| Internet-connected machine using a simple software NC." -- ht
| tps://www.cl.cam.ac.uk/research/dtg/attarchive/pub/docs/at...
| (1998)
| jeroenhd wrote:
| Given the CPU load I've witnessed on VNC servers, I don't
| think "low overhead" is right these days.
|
| VNC was designed for remote desktop use. All the other
| streaming features came along later. I don't see why RDP
| would make for a worse choice here, other than that Windows
| VM integration would make for an better solution.
|
| RDP used to be far inferior because it was proprietary
| Microsoft stuff with buggy open source clients and
| undocumented servers that kept changing stuff around. These
| days, open source RDP server software is actually quite
| solid. I don't know if Gnome/KDE leverage the partial update
| mechanism that makes RDP so useful on Windows (doesn't seem
| to seeing the performance I'm getting out of VMs), but I find
| RDP to be a lot more useful for interactive desktop streams
| than VNC.
| RossBencina wrote:
| > I don't know if Gnome/KDE leverage the partial update
| mechanism
|
| I guess that would be something for the wayland compositor
| to manage. Maybe a wayland compositor that is also an RDP
| server? or maybe they're all like that already?
| tlamponi wrote:
| > I wonder if tools like Proxmox could use this as a more
| efficient alternative to VNC (which is slow and weird) or SPICE
| (for which there are very few non-Linux tools).
|
| Yeah, we at Proxmox are actually evaluating such things, and we
| hope that IronRDP and QEMU display [0] can be part of a stack
| that replaces SPICE in the long term, but it will need a bit
| more time to see how this play out and what exact role it can
| play in Proxmox VE.
|
| Another experiment is to see if we can add a more modern video
| encoding to QEMU, as the recently released noVNC 1.6 gained
| support for H.264 [1]; albeit we naturally would prefer
| something more open like AV1.
|
| [0]: https://gitlab.com/marcandre.lureau/qemu-display/
|
| [1]: https://github.com/novnc/noVNC/releases/tag/v1.6.0
| nemanja wrote:
| Compute overhead of H.264 encoder is non-negligible for a VM
| host where I want all my CPU cycles to go to user VMs.
| Datacenter-class Intel CPUs (Xeon) don't include H.264
| encoders in hardware. QuickSync circuitry is generally
| limited to consumer-grade CPUs. Not to mention MPEG licensing
| issues.
|
| AV1 eliminates MPEG licensing issues, but encoding in
| hardware is even more limited. Also, AV1 is great for encode-
| once use cases (e.g. YouTube) since it's heavily geared
| towards reducing bandwidth requirements vs. encode speed.
| It's workable for real-time streaming in the lowest settings,
| but H.264 is still better overall.
| KennyBlanken wrote:
| > "need a bit more time to see how this play out and what
| exact role it can play in Proxmox VE."
|
| It's been around for six years?
|
| Seems like enough to say "let's try it out, see how things
| go, I bet if we start working with it, things will accelerate
| rapidly" to me.
| kayson wrote:
| This is very cool. I still think MS RDP is the best remote
| desktop client and protocol. The performance is just insanely
| good, and the client is easily available on 95% of computers. The
| multi-monitor support is also awesome. The only downside is that
| it's Microsoft...
| DaiPlusPlus wrote:
| > The performance is just insanely good,
|
| It's still artificially capped to a really awkward framerate
| (maybe 24fps or ~32fps?), even today.
| rcarmo wrote:
| You can set that to 60fps -
| https://taoofmac.com/space/protocols/rdp
| DaiPlusPlus wrote:
| That article instructs readers to use H.264 rendering and
| to set DWMFRAMEINTERVAL - thing is, DWMFRAMEINTERVAL is a
| host-side parameter and apparently all it does is set an
| upper-limit on the possible refresh rate [1], rather than
| force the entire RDP system (client and server) to run at a
| specific frane-rate. This also conflicts with a personal
| experience of mine: possibly around 2007-2009 I remember
| using a FOSS RDP client meant for Linux but ported to
| Windows for some reason, and I preferred using it to
| connect to a shared WS2003 TermSrv box on the LAN because
| _it sure felt like 60fps_ , despite everything else wrong
| with a barely-complete Win32 port (I don't think they even
| used MINGW; mad lads...). It was my own TermSrv box and I
| know I didn't do anything server-side to make it work so
| buttery-smooth.
|
| ...which tells me that the _compromised user-experience_
| caused by the artificially capped frane-rate of the RDP
| session is entirely at the direction of the client, not the
| server. But that was... 15+ years ago (...fuck), it's
| possible the protocol has changed and maybe it's something
| both host and client negotiate, but clearly _its possible_
| and clearly someone in the Windows Server group at MSFT
| enjoys cinema too much because they seem to think 24fps is
| good enough for everyone.
|
| Also, when you use H.264 in RDP, it defaults to 4:2:0
| chroma subsampling[2] which is going to ruin fine-details
| and make text ugly if not unreadable - there's a reason we
| use H.264 for movies but not text documents. I remember
| around 2013 when a bunch of competing remote-access
| companies all launched hardware-accelerated-video-based
| remote-desktop products and being impressed with how they
| handle remote-Netflix over a pre-LTE mobile tether, but
| reeling and gasping to throw-up after their aggressive
| codec motion-estimation, subsampling, and YUV colorspace
| absolutely butchered a 100% zoom Word document with
| ClearType enabled. Using the system instilled oneself with
| a strong discipline against ever moving or resizing a
| window on the desktop, lest _the smears_ of low-bitrate
| macroblocks start to appear, warning you the text-on-screen
| is about to become painfully unreadable for the next few
| seconds while you curse the DSL connection you're still
| forced to use because your apartment complex's HOA got a
| sweet deal on satellite TV from the incumbent telco by
| blocking the local cableco, with their sweet sweet DOCSIS
| 4, from adding service to the building and I'm done.
|
| [1] https://learn.microsoft.com/en-us/troubleshoot/windows-
| serve... [2] https://learn.microsoft.com/en-
| us/azure/virtual-desktop/grap...
| sitkack wrote:
| And they claim patent protection on it. You have to buy a
| license for Microsoft.
| IcyWindows wrote:
| Still?
| tracker1 wrote:
| The main protocol should be well outside patent protection,
| but some of the extensions (RemoteFX, audio support, etc)
| may still be covered, would have to double-check. Likely
| fine.
|
| I would like to see something as capable make its way into
| Linux and Mac that's as ubiquitous. RDP tends to work
| better than the VNC options most other solutions are using
| under the hood.
| bee_rider wrote:
| I'm really baffled as to why anybody would downvote this
| comment, anyone want to explain?
| iforgotpassword wrote:
| How about spice? I don't know anything about the
| technical details, but it seems to offer most of the
| advanced features like usb redirect and I think currently
| gets video support. It's currently really only used in
| qemu but I don't see a reason why you can't use it as a
| general open rdp alternative.
| qsort wrote:
| It's very good at being a remote _desktop_ protocol, but the
| fact that it lacks features like tunneling and that
| authentication is the usual MS mess makes me wish they just
| went with SSH as transport protocol.
| tomjakubowski wrote:
| Windows does support SSH now, so maybe you could rig RDP-
| over-SSH yourself with port forwarding.
| p_ing wrote:
| RD Gateway leverages SSL for encrypted transport for RDP
| between client and host. Maybe it is possible :-)
| awakecoding wrote:
| RDP-over-SSH will break Kerberos authentication for two
| reasons: 1) you'll point the RDP client to localhost and a
| random port and 2) you won't get a KDC line-of-sight. The
| irony is Microsoft has demoed this with SSH over Azure Arc,
| which can only result in an NTLM downgrade.
|
| IronRDP is designed to work with Devolutions Gateway
| (https://github.com/Devolutions/devolutions-gateway) for
| just-in-time RDP connections made from the web or through
| the desktop client. Devolutions Gateway also supports just-
| in-time KDC proxying alongside the main RDP connection,
| making Kerberos possible.
|
| You can install the free standalone web access package of
| Devolutions Gateway to try it out, it will give you a
| simple web interface where you can enter the hostname,
| username and password.
|
| But if you really want the simplest solution, it's with the
| rest of the Devolutions stack with Remote Desktop Manager
| and Devolutions Server. In the end, you'll be able to make
| RDP connections from RDM or through the web with just a
| double-click, and it'll automatically generate short-lived
| tokens and make RDP + Kerberos work seamlessly:
| https://devolutions.net/gateway/
| cryptonector wrote:
| Kerberos has a protocol for when you don't have a line of
| sight to the KDC: IAKERB. IIRC MSFT is very interested in
| it in order to kill off NTLM finally.
| password4321 wrote:
| > _lacks features like tunneling_
|
| TCL over RDP is technically barely possible with a
| ridiculously custom client and a server-side stub:
|
| https://rdp2tcp.sourceforge.net/
| donnachangstein wrote:
| > that authentication is the usual MS mess
|
| You mean seamless integration with AD and supports smart
| cards?
|
| > makes me wish they just went with SSH as transport
| protocol.
|
| RDP predates OpenSSH by a year.
| Fidelix wrote:
| According to Wikipedia, RDP = June 16, 1998 SSH = 1995.
| OpenSSH = 1999
| p_ing wrote:
| RDP is based on Citrix ICA which builds on Citrix
| Multiuser released in 1991 for OS/2, and 1992 for DOS,
| 1993 for Windows.
|
| https://www.basvankaam.com/2017/03/29/a-lesson-in-
| history-th...
|
| The Citrix/Microsoft relationship is a bonkers story. The
| world didn't yet know that licensing your tech to
| Microsoft meant you were going to grab your ankles.
| KennyBlanken wrote:
| In the several decades since, nothing has stopped them from
| coming out with a "RDP v2."
|
| I trust SSH to be public-facing. Don't have the right
| private key? Pound sand. You're not getting in.
|
| I trust RDP to allow someone to break into my machine, get
| admin privileges, and infect / bot it, likely in under an
| hour.
|
| Smart cards _rolls eyes_
| naikrovek wrote:
| Do you not remember the Microsoft of the late 1990s?
|
| We're lucky it didn't cost $250/seat. And we're luckier that
| it's effectively an open protocol, today, though there are
| still license considerations if you are reaching into
| Windows.
|
| I was a remote system admin BEFORE Remote Desktop. It was not
| fun. I would have gladly paid $500/seat at the time for RDP,
| if that's what it cost.
| SirMaster wrote:
| I feel like a more modern approach like whatever RustDesk uses
| is way better. It has such good performance that I can
| practically play an FPS video game through it or watch a movie
| through it.
|
| The big thing I hate about regular Microsoft RDP is you aren't
| getting to use your remote GPU through it.
| raggles wrote:
| > you aren't getting to use your remote GPU through it.
|
| Um yes you are? I use AutoCAD and other software using GPU
| all the time over rdp
| vekatimest wrote:
| I've had issues with some software & games not being able
| to get a proper display context and refusing to start.
| raggles wrote:
| Yes I have seen OpenGL applications refuse to start with
| AMD cards in some circumstances due to a bug in the AMD
| drivers, but never had a problem on NVIDIA cards
| jeroenhd wrote:
| RDP GPU acceleration should be available (on Windows, at
| least) with the right quality settings. AFAIK nothing API-
| wise prevents GPU software from running. That said, RDP is an
| edge case few software developers bother testing so I'm sure
| there are lots of programs out there that ignore edge cases
| when it comes to rendering APIs.
|
| It's not optimised for games, though. Something like Parsec
| would be much better for interactive stuff like that, or
| maybe something like Moonlight for Nvidia cards if you're
| looking to go without closed source software.
| SirMaster wrote:
| I know it's not made for games, but the thing is I am
| seeing Parsec-level performance and quality from RustDesk
| which why I am liking it so much.
|
| With modern hardware with RustDesk you are getting HEVC or
| even AV1 hardware encoded high framerate stream of your
| desktop.
|
| I have never seen this kind of performance through MS RDP
| personally.
| magicalhippo wrote:
| RDP also supports streaming regions, including the entire
| desktop, as hardware-encoded video. It was introduced 9
| years ago[1].
|
| As for performance, I've been playing full-screen games
| over it. Latency sucked when I was literally on the
| opposite side of the earth but if the bandwidth was there
| it worked fine.
|
| From work to home RDP is typically indistinguishable from
| being local for me.
|
| [1]: https://techcommunity.microsoft.com/blog/microsoft-
| security-...
| ziml77 wrote:
| I tried using RustDesk, but it gave me absolutely no feedback
| after I entered connection info for my local ID server if it
| was actually using that or not. I tried enabling debug
| logging to get a better idea of what was going on, but that
| wasn't working for me. When I got to the point of trying to
| figure it out through Wireshark, I realized that was stupid
| to even have to do and just gave up on RustDesk.
| twooclock wrote:
| You gave up too early! I host my own server on a 5$ DO
| droplet. Have >100 clients, RustDesk never failed me once.
| Works like a charm.
| RockRobotRock wrote:
| Do you think it's good enough for "business"? I pay too
| much for screenconnect and absolutely hate it, but it
| does usually just work.
| wkat4242 wrote:
| It's usually pretty good on windows because it does a lot of
| local drawing but most Linux servers don't support that and use
| it just as a dumb blockpusher like VNC :(
| aappleby wrote:
| If you think RDP performance is good, you should try
| Sunshine+Moonlight. I regularly stream at 4k 120hz from my
| gaming PC to my laptop and it's basically indistinguishable
| from running locally. I've even run it over Tailscale from a
| thousand miles away (though at 1080p60) and it was still
| markedly better than RDP.
|
| Caveats - You really want a Windows host for fully accelerated
| on-GPU hardware video encoding, the server setup is _slightly_
| more involved than RDP which is usually preinstalled, and
| Sunshine+Linux+NVidia requires an annoying driver patch. But
| overall it's _amazing_.
| winkelmann wrote:
| I'd still pick RDP for remote managing any day, its server
| and client are so much better integrated (clipboard,
| peripherals, etc.) for this task than Sunshine/Moonlight. It
| also avoids the whole issue of setting up a virtual display
| output[1] as is required by Sunshine. I use both for
| different tasks.
|
| On a related note, as of recent versions, Sunshine and
| Moonlight stable releases support 4:4:4 chroma subsampling
| and bitrates up to 500Mbit/s with HEVC, which results in
| almost indistinguishable image quality compared to native
| output[2]. Bitrates that high are unusual in normal content,
| but at least Apple's Media Engine (on M-series Macs) appears
| to be capable of decoding it.
|
| [1] Here is a pretty good solution that piggybacks off of
| Parsec's driver, which is fully signed, though its EDID lacks
| HDR support. The project also includes a C header file for
| custom implementations: https://github.com/nomi-san/parsec-
| vdd
|
| [2] Note: I found that I had to enable 10-bit color streaming
| (which is available when using Parsec's driver) to get rid of
| some gradient banding that isn't present in native 8-bit. I
| suspect it's some encoder and/or color space issue.
| gryn wrote:
| TBH, After trying both I'd still pick RDP (I used xRDP server
| on linux) for anything text/GUI related. RDP(not VNC or VNC
| larpin as RDP) doesn't make image compression artifacts when
| the connection gets bad it's just add some lag keeping the
| text crisp.
|
| Sunshine/Moonlight on the other hand reduce image quality
| keeping the latency low, which is really good when streaming
| games for example.
| Hard_Space wrote:
| > Sunshine/Moonlight on the other hand reduce image quality
| keeping the latency low
|
| You can set it to any speed, including LAN speed, according
| to the available bandwidth/connection.
| Hard_Space wrote:
| I use Sunshine and Moonlight when I'm out away from my
| Windows laptop in my home office and back near the router in
| the front room over my Macbook air, it's great when you can
| get directly on the LAN with it. But then, RDP is also better
| over the LAN, and casual disconnection is easier.
|
| But if I want to do graphics-intensive work on the headless
| tower, I'll use Sunshine and Moonlight.
| RockRobotRock wrote:
| If you got remoteFX on RDP working, would the difference be
| that large for gaming?
|
| One feature I really want is clipboard sharing that works as
| well as it does on RDP/Parsec.
| jwrallie wrote:
| There are a few disadvantages, in sunshine/moonlight such as
| you still have monitor output, so you are stuck to the
| resolutions supported by your monitor and someone can see
| what you are doing. Of course there are workarounds like
| dummy monitors.
|
| I do not have clipboard sharing working (I'm not sure if it
| is even supported) and there is a bug where some specific
| keys (including \\) do not work on some keyboard layouts
| (Japanese for example), although there is already a pull
| request that supposedly fix that.
|
| Still it is an amazing solution. The snappiness of having
| full 3D acceleration is amazing, and as another plus it works
| in the home edition of Windows.
| deeviant wrote:
| My buddy was absolutely delighted by Sunshine+Moonlight and
| basically forced me to try it. Long story short, it is not
| nearly as responsive for dev tasks, amazing for gamings or
| streaming, however.
| cryptonector wrote:
| Anytime there's a timeout the Microsoft RDP client makes you
| wait way longer than you might have had to otherwise. That
| kills me.
| singhrac wrote:
| It is really nice, I'm very sad that Apple's RDP
| implementations seem fragmented and difficult to use. I've
| tried a few times with my Mac Mini, and it just doesn't seem to
| work that well.
| naikrovek wrote:
| They use simple VNC but with some special "applesauce" that
| makes every non-Mac client I have ever tried break after a
| minute or so.
|
| But, on a mac, when you "screen share" into another Mac (this
| is what they call it for some reason; you "screen share into"
| the remote) it is flawless and quite snappy.
| nailer wrote:
| Fedora recently ditched VNC support in their installer for RDP.
| https://docs.fedoraproject.org/en-US/fedora-server/installat...
| (which may be a Wayland think, I just know more about Fedora than
| general Linux distros).
|
| RDP seems to have taken the zeitgeist in the open source world.
| IshKebab wrote:
| It is a lot more advanced than VNC, and the open source world
| doesn't seem to have come up with any alternatives.
| InsideOutSanta wrote:
| RustDesk is intended to be a TeamViewer alternative but works
| quite well as a simple remote desktop application:
|
| https://github.com/rustdesk/rustdesk
| raphinou wrote:
| I thought to have seen some negative comments about its
| security, anyone knowing more about it?
| InsideOutSanta wrote:
| I haven't heard anything negative about it, and I can
| only find one CVE:
|
| https://www.cvedetails.com/cve/CVE-2024-25140/
|
| Personally, I'm not exposing my installations to the
| Internet, so I feel relatively secure regardless.
| Arrowmaster wrote:
| They installed a root certificate on windows computers
| that could have been used to MITM all traffic.
|
| I personally had issues with the project years before
| that when I tried to install their Linux .deb and they
| ran `pip install` as root in the pre install script
| inside the .deb. That caused so much havoc to clean up I
| was pissed at them for years. Now that idiocy is blocked
| by default in current versions of pip.
| IshKebab wrote:
| Yeah it just seemed like a slightly suss project to me. I
| did use it initially but uninstalled it after the Chinese
| root certificate incident.
|
| I wonder if anyone has forked it...
| rrdharan wrote:
| I don't quite understand what happened to SPICE. I know Red
| Hat deprecated it, and I can't tell if it was ever fully
| opensourced or not?
|
| https://www.spice-space.org/developers.html
| spookie wrote:
| My theory is Wayland happened. As SPICE doesn't work that
| well through it. I would assume it's another case of a
| "niche" the Wayland protocol didn't account for, however.
| jeroenhd wrote:
| Interesting theory. Any idea on why SPICE wouldn't work
| well through it? I don't have recall running into any
| issues with it.
|
| A more Wayland-oriented remote desktop protocol would
| probably make for an even better VNC alternative, but I
| don't really know why SPICE never got the uptake it
| deserved.
| timewizard wrote:
| Wayland. Move slow and break everything.
| j16sdiz wrote:
| I thought RDP is highly coupled with GDI. How could it
| translate native wayland to GDI?
| p_ing wrote:
| That is one of the extensions, in theory others could be
| built. RemoteFX is an extension as is the (more normal today)
| Desktop Composition Extension.
|
| https://learn.microsoft.com/en-
| us/openspecs/windows_protocol...
| awakecoding wrote:
| The Desktop Composition extension was never used in
| practice, check the date on the spec - the last update was
| in 2017. I don't know the whole story behind the scenes but
| the feature got pulled early.
| tracker1 wrote:
| Possibly a patent threat.
| awakecoding wrote:
| The RDP GDI messages are from RDP6, graphical messages have
| changed many times over in the versions of RDP that followed.
| Would you be surprised to learn that WSLg uses a FreeRDP
| server hooked to a Wayland compositor running in the Linux
| guest, and that the RDP client in the Windows host is MSRDC
| in a special RemoteApp mode? In theory someone could build a
| similar RDP server using IronRDP
| johnisgood wrote:
| Well, I personally never had any issues with X11vnc ever since
| its existence. I have used it a long time ago though.
| int_19h wrote:
| This probably has something to do with Gnome on Wayland having
| RDP server support as a standard feature:
|
| https://gitlab.gnome.org/GNOME/gnome-remote-desktop
| graynk wrote:
| I get the whole Rust -> Iron thing, but when I see Iron prefix I
| think of dotnet because of https://github.com/ironlanguages and
| https://ironsoftware.com/
| TheRealPomax wrote:
| Given that it's an implementation of Microsoft's RDP, not sure
| that's a "but" in this very specific case =)
| badlibrarian wrote:
| I think of IronPython and IronRuby and IronScheme, early
| attempts at Microsoft trying to combine cornmeal with .NET and
| open source and calling it a burrito.
|
| https://ironpython.net/
|
| https://en.wikipedia.org/wiki/IronRuby
|
| https://en.wikipedia.org/wiki/IronScheme
| graynk wrote:
| yep, that's my first link
| SpaceL10n wrote:
| Iron Icons comes to mind as well
|
| https://www.webcomponents.org/element/@polymer/iron-icons
| tracker1 wrote:
| That was my first thought as well. Surprised to see they're
| still seeing updates. Also surprised to never see an IronJS or
| IronTypescript or similar really.
| snoman wrote:
| It be weird to see MS make an IronTypescript given that they
| created typescript.
| tracker1 wrote:
| TypeScript as it exists from Microsoft isn't a runtime
| engine.
| ffsm8 wrote:
| Wouldn't that be IronNode, then? Especially now that
| node-ts is a thing
| int_19h wrote:
| Early .NET (pre-4.0) included JScript.NET, which was
| effectively "IronJS", except that it predated the convention.
| 38 wrote:
| cannot build for windows ironically
|
| https://github.com/Devolutions/IronRDP/issues/709
| stodor89 wrote:
| IRONically, hehe
| jeroenhd wrote:
| The error says cmake is missing, not that it doesn't build on
| Windows.
| 38 wrote:
| Just what I want, a C requirement for a Rust project
| paulddraper wrote:
| Sounds like it's not your Rust project.
|
| But cmake is required by Rustls (or more precisely, aws-lc-
| rs).
| iJohnDoe wrote:
| Is this available for Linux? Linux desperately needs RDP. Any
| Linux distros with RDP built-in?
| mhurron wrote:
| XRDP? Only real problem I know of there is it doesn't support
| Wayland.
| allanrbo wrote:
| Yes, Gnome on Ubuntu and Debian has had a built in rdp server
| for the last several releases: settings -> sharing -> Remote
| Desktop -> on
| Saris wrote:
| For some reason the performance with those is never on par
| with windows RDP, it feels a lot more like VNC.
| rcarmo wrote:
| Look into installing xorgxrdp-glamor and openh264.
| jeroenhd wrote:
| It's unfortunate Ubuntu doesn't enable that by default.
| I'd compile the software myself, but for daemons like RDP
| I'd rather receive regular security updates...
| rcarmo wrote:
| Look into installing xorgxrdp-glamor and openh264. I have zero
| issues in Fedora, at least, and most of my Debian machines
| (even ARM) have equivalent packages (although sometimes without
| full acceleration).
| alexpadula wrote:
| That is mighty impressive. Thank you for sharing!
| shravankumar8 wrote:
| amazizng
| paulddraper wrote:
| That's...a confusing name.
|
| Given that IronPDF, IronXL, IronQR, IronBarcode, IronZIP,
| IronPPT, IronRuby are written in C#/.NET.
| awakecoding wrote:
| My apologies for the name choice, I actually didn't know "Iron"
| was taken for a lot of C#/.NET projects. We were looking for
| something that meant "hardened" because it's written in Rust,
| and went for "IronRDP". This being said, we're generating .NET
| bindings to IronRDP which we use in Remote Desktop Manager.
| password4321 wrote:
| This is great. I'll have to look into spinning up a client for
| out of support Mac OS editions via macports -- the last version
| of the official client sometimes crashes eating up GB of RAM.
|
| I also would like to integrate smart card support into the client
| instead of passing through the hardware to the host... entering
| PINs through the normal remote UI always gives me the heebie-
| jeebies.
| MasterYoda wrote:
| Which good free open source alternatives for remote desktop on
| win 11 are there where you can install both a server ()for win11
| home that have the rdp server) and have a client you connect
| with? Knows only about VNC, but never liked it? And ironrdp just
| looks like the client. Whant to selfhost the server.
| eitland wrote:
| Based on what I see under
| https://github.com/Devolutions/IronRDP?tab=readme-ov-file#ho...
|
| it seems like the server part is Windows only?
| seritools wrote:
| It's instructions for the Windows RDP server to enable RemoteFX
| support so that the Rust client can make use of it.
|
| Maybe I'm missing something, but for the server side it's only
| crates that help you build your own server, no direct
| integration with any system, be it Windows or otherwise.
| eitland wrote:
| Ok, so there is a server for Linux as well?
| shmerl wrote:
| How does it compare to freerdp feature wise?
| inetknght wrote:
| > _1. Julia has two sisters. That means there are three girls in
| total (Julia + two more)._
|
| False. Julie could be the name of a boy.
|
| > _2. Julia also has one brother, named Martin._
|
| OK
|
| > _3. Altogether, there are four siblings: three girls and one
| boy (Martin)._
|
| Where did you identify the third girl?
|
| > _4. From Martin's perspective, his sisters are all three of the
| girls (Julia and her two sisters)._
|
| Here's where the answer comes from (Julia and _her_ two sisters).
|
| More directly: "How many sisters does _her_ brother Martin have?
| "
|
| > _5. Therefore, Martin has three sisters._
|
| OK.
|
| So the reasoning might have come to the "right" answer but the
| way it arrived at the answer was incorrect.
| stuaxo wrote:
| Ooh.. if this could support GfxRedir, then it could open up
| various interesting virtualisation things.
| reneberlin wrote:
| "With a focus on security" was the punchline and i had to smile.
|
| While i encourage the great intention and the work that has been
| done, it seems an oxymoron to create a secure client to connect
| to unsecure clients.
|
| I will never forget that blazing speed of the BlazeRDP-
| implemetation that i used in the past that is now long forgotten.
| I never saw such an speed-optimized RDPish implementation. I knew
| i was connecting to unsecure clients and used a propietary fix to
| a MS-based protocol, but it was insanely fast. I never had such a
| fast remotedesktop since then regardless of the OS. This is not
| an ad, i'm not affiliated, it's simply a fact in my life, that i
| recall.
| Fidelix wrote:
| Any links to share? I don't care about security for my use
| case.
| RandyOrion wrote:
| Just a random note.
|
| As someone in this thread already stated, if you want smooth
| remote desktop experience with security requirements, you may try
| sunshine + moonlight for streaming with tailscale / zerotier for
| connection.
| znpy wrote:
| Just a quick note from somebody who's been tinkering with RDP:
| RDP is so much more than remote desktop, and this ironrdp thing
| looks cool but is also severely limited.
|
| xrdp supports forwarding audio (playback and microphone
| forwarding, both ways) as well as local folder forwarding. And I
| think i also got webcam working (webcam on my laptop forwarded to
| the browser running on the remote host).
|
| for reference: https://www.xrdp.org/
|
| I hope this implementation gets to a maturity level to make it
| actually usable for realistic remote desktop usage :)
| gHA5 wrote:
| Remote Desktop Protocol protocol
| buybackoff wrote:
| Is it feature-complete with RDP and then some? As someone who has
| spent, over the last ~15 years, probably equal amount of screen
| time on RDP vs local (even in the office it's usually RDP to a
| blade, and at home a laptop to a powerful workstation; with
| remote work recently it's so much more and often nested), and
| someone who tried Linux on Desktop regularly and gave up because
| of inferior RDP alternatives (even GNONE 47 is a joke for RDP,
| but getting closer), - I learned to appreciate all the tiny
| details that make the RDP proper great.
| kuon wrote:
| Do you know a good client on linux with Wayland support? I have
| artefacts with all clients I tried.
| jdadj wrote:
| Probably coincidentally, in a blog post today, Cloudflare
| announced clientless, browser-based support for RDP. It seems
| they're using IronRDP under the hood.
|
| https://blog.cloudflare.com/browser-based-rdp/
___________________________________________________________________
(page generated 2025-03-21 23:00 UTC)