Remote Desktop Protocol Improvements in Windows 10 | Hacker News Reader

Remote Desktop Protocol Improvements in Windows 10

blogs.msdn.com

76 pointswalterbell45 comments

Wow.

For example, with Windows Server 2016 Technical Preview we now enable OpenGL applications with RemoteFX vGPU scenarios which enables support for additional high-end engineering design applications that use OpenGL.

This strikes me as really huge. For a while one of the intrinsic advantages of X over the Windows GUI was the ability to have remote, accelerated OpenGL sessions over GLX. Linux GUIs have pretty much abandoned proper support of this but Windows is getting it?

xfreerdp supports it. And I think there are GLX enabled VNC clients and servers.

Linux unfortunately has been getting worse in a lot of ways, as the old-timers get too old/busy to bother with it, and the hipsters take over. A prime example of this is Gnome3.

When Linus and his lieutenants retire, Linux is really going to go downhill fast.

An interesting sentiment, but Linus and his lieutenants were never very responsible for graphics.

I wonder what will happen when those guys retire but it might end up being positive. Linus and his lieutenants have been spazzy about filesystem advancements, a kernel debugger, and in general a bunch of other stuff.

Or maybe everyone will just use BSD.

There's nothing stopping anyone from forking the Linux kernel and adding their own advanced features if they think they're so valuable. Almost no one even uses a vanilla Linus kernel; distros all have their own custom kernels. So the fact that no one's bothered making a big competitor to Linus's kernel (which of course would mostly be a drop-in replacement) means that either no one thinks these things are useful, or no one's really competent enough to do it (and willing to spend the time/effort). As for filesystem advancements, they're working on btrfs; what more do you want?

> they're working on btrfs; what more do you want?

Ha ha ha etc.

Wow, that's an intelligent answer.

I actually don't know if you were joking or not, but "what more do you want?" sounds somewhat sarcastic to me. In any case, btrfs is a mysteriously sad, pathetic response to ZFS. It's worth a chuckle regardless.

The short answer to the "what more do you want?" question is that I'd like developers to come to their senses and adopt FreeBSD. Since that's not going to happen... I don't know, a puppy? Or core linux devs acting with more taste. I'll be fine if I don't get either.

btrfs has better and more features than ZFS; it's just not as mature yet. And ZFS can't be used in the Linux kernel because its license is incompatible. If you have a problem with that, I suggest you complain to the owners of ZFS.

What's so great about FreeBSD? I see BSD people say that all the time, but you never see much actual usage of BSD anywhere. Instead of almost all developers being wrong, maybe you're the one who's wrong.

Acting with taste? That's completely irrelevant to technical issues.

> Instead of almost all developers being wrong, maybe you're the one who's wrong.

It's so hard to tell how much of what you're saying is meant to be taken seriously or responded to.

Regarding BSD, it's worth spelunking through the comments here with a search and then trying it for yourself. These forums run on FreeBSD, I'm not sure if you knew that.

One problem I've always had with RDP is its UX/performance when it comes to bandwidth-rich/ultra-low-latency environments like interacting with locally running Hyper-V virtual machines.

VMware Workstation and VirtualBox have always had a better UX when it comes to interacting with local VMs that is nigh indistinguishable from native. Whereas using Hyper-V, for some reason we have to deal with graphical compression artifacts everywhere and what sounds like 128kbps audio. Though I'm not sure if this caused by a limitation of RDP or of Hyper-V itself.

Has this situation gotten any better with Windows 10's RDP/Hyper-V implementation?

I've been using Windows 10 over RDP for about 1.5 years now. Performance is pretty nice even over 4G. Often 30-60 fps. Text is very sharp and movement (except when HiDPI is in use, see below), such as scrolling or moving windows is fluid. Full screen video works just fine, be it Youtube in a web browser or VLC. Complex websites with WebGL and flashy CSS effects work smoothly.

Two issues I've noticed:

1) Color accuracy is really bad. For example when scrolling a website, sometimes you get yellow artefact blotches over white areas. Forget about using this for anything that needs color accuracy. Other JPEG-like compression artefacts are also present.

2) Performance becomes very bad when display scaling is not default 1:1 at server side, when using HiDpi. Compression artefacts go off the roof as well. Text becomes very blurry.

In those situations try Ericom Blaze

You would think raw "feedthrough" would be literally the easiest scheme to support.

Are these enhancements to the protocol, or just the implementations? The article doesn't seem to distinguish the two, which always makes me a bit uneasy, because it could be a sign of not caring about the protocol as such (and third-party implementations thereof).

The improvements are cool and all but IMO all this is unneeded if Windows just had a proper terminal with lots of little utilities.

Powershell. Yea it looks different than bash but it's great.

But RDP solves different problems. I do UI development and use RDP to connect to my work box from home. It's also used on Windows Server for Citrix-type scenarios.

Comparing powershell to a UNIX command line is like bringing a tricycle to the Tour de France.

Passing strongly typed objects between processes seems better than text and streams, if only for auto complete.

That part is great. The problem with Powershell is that Windows doesn't have a culture of using the shell in general or it being an area developers should be good at, whereas Unix inherits half a century of a shell being the primary means to control a system. This shows painfully any time you try to use PowerShell seriously outside of Microsoft's core enterprise IT management – documentation is non-existent, hard to find, out of date, incomplete, etc. while many applications either don't support it at all or expose only limited functionality, and so forth.

I think Niels had it exactly backwards: PowerShell is like taking your bike from the Tour de France and trying to ride through a rural area with no roads. All of the advanced technology doesn't help if you're trying to do something which just isn't commonly done there.

The thing which I think will change that is Azure – almost any time I see someone mention using PowerShell for real work, it involves Azure and that seems likely to continue improving as people start doing the hybrid cloud model. It's one thing to click around in a GUI when you periodically setup a few gigantic servers or deploy every 3 months but it's quite a different world when you are talking about running a dozen cloud servers for 3 hours.

The good news is that there is a Microsoft directive that major Microsoft software should come powershell admin tools.

I think a lot of config gui's now just execute powershell underneath.

Hopefully they'll be able to shift the culture to the point where enterprise IT managers start writing that into purchase requirements. That could make lives better for a lot of Windows admins very quickly.

Most of the stuff that comes out of azure UI just runs powershell stuff. The release flow for new features tends to be powershell private preview -> general availability of commandlets -> UI full release. Most of the Azure stack has extra features that are never really ported to the UI.

I don't like the powershell, and even I know that's an absurdly unfair bias.

Very true, but I suspect you're mapping them the opposite way.

Back in the 1990s we had X Windows in our computer lab and it was routine to run an app on one Sun workstation and interact with it on another. This "just worked" with Linux and in 1995 I was laughing at RDP and crashy Windows 95 and NT.

Around that time KDE rocked the world with a beta release desktop that "almost works" but since then the Linux desktop has stagnated rather than advanced.

To the best of my recollection, Windows 95 didn't have RDP at all. Neither did NT (<=4) except for Terminal Services Edition, and even then it was pretty good for its day.

This all said by me, who was a full-time Linux/Solaris (and X) user who was involved with Windows as part of my day job.

Back then we were trying to get a Windows NT network to behave more like a traditional Unix cluster so we were messing around with Terminal Services and other work-arounds that didn't quite work at that time.

RDP solves problems way outside that use case. The upcoming ssh native ssh server looks nice, but RDP exists for working with GUI applications. Windows' rasion d'etre is, well, Windowed applications as a alterntive to the command line stuff that ruled in the 1980s in business, so its no surprise that even its server end is largely graphical, at least from a legacy perspective. MS is pushing powershell admin tools very hard in its own products and encouraging other vendors to do so.

From the CLI, I get by with psexec and the standard windows command line tools, many of which are fairly powerful and "good enough" for Windows administration even before ps existed. I manage roughly 100 windows PCs this way without issue. Group Policy is also hard to beat. 90% of our administration is done just with GPO's. The PCs and servers are automatically configured from soup to nuts once they join the domain. Changes are trivial to make and percolate to all systems. Its actually quite pleasant.

In the linux world, this is all a PITA as the CLI doesn't really help with with Windowed userland issues (firefox looks funny, cant click on something, etc). NX helps but generally we just used third-party remote stuff. VNC is a massive security hole that should never be used. Nowadays, this isn't even a concern as the linux desktop is pretty dead in my industry. OSX ate whatever goodwill it had for most.

And I wish there was a proper desktop for Linux and OS X - but there's not. I'm guessing this is the right place for that complaint?

Speaking of RDP though, I have yet to find a remote screen sharing tool that is as polished and that works as well on Unix as RDP does on Windows. I'd really like to be able to use something other than VNC to remote into my Mac from Windows.

NoMachine's solution comes close, but is still not as robust over flakey connections as RDP. I've yet to experience the kind of tolerance to slow/poor connections I get with RDP over NoMachine when run over either a very spotty cellular Internet connection (3G-grade will really point this out) and over an airliner's satellite Internet connection. As odd as it may seem, when I want a solid X11 experience over a flaky Internet connection, I spin up an X11 window server on a Windows desktop, and RDP into that desktop session. RDP degrades much more gracefully than the Unix-based options, and isn't as aggressive with timing out and breaking the connection.

I also looked at the SPICE protocol and its implementations [1], but again the user experience is poor over slow/flaky connections compared to RDP. The compact RDP data stream also makes it a good starting point for developing various RDP-based recorders.

In my opinion, RDP is a much-overlooked feature of Windows, and its superior implementation to any Unix alternatives I'm aware of is one of the reasons I still run some Windows instances in my environment.

https://en.wikipedia.org/wiki/SPICE_%28protocol%29

NoMachine offers two methods when delivering a remote Linux/Unix desktop: 1) NX in 'lightweight mode', mainly using advanced compression and caching of the X11 protocol and 2) NX using hardware accelerated video encoding and decoding.

The first method is the preferred option when connecting to legacy X11 applications, i.e. applications making mostly use of traditional X11 Render operations and X11 vector graphics. In this 'lightweight mode' NX reduces both the bandwidth usage and the HW requirements on the client and the server to the very minimum, by employing the expensive video encoding operations only when detecting that the server-side application is producing video data on the screen.

Unfortunately this 'lightweight mode' can't deliver games, a Mac or Windows desktop, as well as most contemporary Unix/Linux desktop environments. The reason, in the latter case, is the inefficient way these applications use the X11 protocol, as well as the inability of the X11 protocol to deal with modern graphics. In these cases, the use of video encoding is unavoidable. NX employs a number of different techniques to reduce the CPU consumption and the bandwidth needed, so much to often make video encoding advantageous even compared to the legacy X11 protocol compression. But, of course, the final results always depend on the screen content being deployed.

Disclaimer: I work for NoMachine

Thank you for the clarification, that helps explain a lot. Next time I fly and/or hit a 3G area I'll try running the older X Window manager fvwm v2.x under NoMachine and compare to the RDP-based results. I'd really prefer to work with NoMachine because it preserves my Linux- and BSD-based stack, so if it works as well as RDP I'll try to remember to post back here my results.

I agree. VNC is a great hack, but it is a hack.

Windows RDP has been amazing for modern desktops. Prior to having over 8GB RAM and an SSD drive, I would often access Windows from by Mac via RDP. Since I am mostly Mac OS X, Linux or Windows visualized on my Mac these days, I seldom use it RDP, but I am always amazed at how responsive it is compared to VNC.

The best remote desktop I have used was Timbuktu for Mac back in the early 90's. At that time, Timbuktu was able to utilize the Mac's great support for 1-bit (black/white) and other low-bit graphics modes, and you could have a very good remote experience even at high display resolutions via a 14.4kbps modem. Putting Mac OS X into gray scale mode helps, a little but VNC performance still sucks.

I also remember seeing an amazing demo of a NeXT system that was able to push its Display Postscript based terminals to remote systems. Alas, Apple lost that when Display Postscript was replaced by PDF.

The biggest improvement I've seen is that I'm now automatically disconnected after 10 seconds.

Not a big Microsoft fan in general, but must admit that RDP is a nice protocol with good performance relative to some of the other protocols.

This post doesn't mention it but I noticed that RDPing to a remote Windows Server from Windows 10 now requires the server to be using a certificate.

I'm pretty sure it doesn't need one - it just warns you if the remote server doesn't have one. Kind of like how browsers will warn you if a remote site's SSL cert is bad, but they'll let you through if you insist.

That's not my experience, it insists and refuses to connect.

Edit: I'm not sure who downvoted me, what do you want me to post a screencast to prove it? Do you think I'm making this up or what?

what do you want me to post a screencast to prove it?

Given that multiple people are replying to you saying that they do not experience the same thing... yes, probably.

On your Server, check the Computer Properties for Remote Access. One property discusses allowing Remote Desktop, another discusses mandating certificates, versus warning.

It doesn't require one, unless your group policy (or local server policy) has been set as such.

That's not what I've seen. No policy has been changed on my Windows Server, Windows 7 and prior RDP clients connect fine, Windows 10 clients refuse because of lack of certificate.

I just tested on a fresh windows 10 install. Works fine.

Windows 10 to Windows 2008 R2, no cert. I just click past the warning. Everything works just as it did with Win7.

Reply on news.ycombinator.com