a low-key online “Windows Server Summit”
So low-key, I didn't know about it.
Microsoft has teased some coming-real-soon-now features for future editions of Windows Server. The software behemoth last week staged a low-key online “Windows Server Summit” that concluded with principal program manager Ned Pyle showing off features including auto-compression of files before they’re moved. Pyle first …
...be added to Windows 10 Pro. Then people would be able to see the glorious benefits of the server tools on a properly updated OS. It appears they've started doing this already with Windows 10 20H2, as it now has Remote Desktop Services installable and licensable if you install the feature with DISM. I hope more is around the corner.
Windows services (in the main) use standardised RPC protocols for remote administration, have very stable codebases and are infinitely easier to script/automate consistently (thanks, Jeffrey Snover) and run as reliably as their Linux equivalents in my experience. The only downside I see is that they're less flexible in configuration and seem to lack the sweet spot in logging for debugging rare edge cases.
However, a complete feature set would make available:
* AppLocker as an extra layer of anti-malware protection
* Proper IPSec, SSTP and IKEv2 VPN server support
* Proper IIS with FTP, HTTPS and SMTP (no connection limits)
* PCI-E passthrough on Hyper-V (Discrete Device Assignment)
* DHCP, DNS servers for replacing crappy home router implementations
* Decent PXE/TFTP services (Windows Deployment Services)
* DFS Replication/Namespaces (compresses and syncs better than rsync)
* Server Resource Management (RAM limiting and scheduler policies for apps)
* NTFS/ReFS Deduplication (gives you a situation on par with ZFS)
* RD Gateway (to make existing RDP more secure over the Intermet)
...and much much more
Well, one reason for that...
From the article:
Using QUIC will make SMB ready for use in mobile and edge applications, Pyle said.
https://en.wikipedia.org/wiki/QUIC has this to say:
Another goal of the QUIC system was to improve performance during network-switch events, like what happens when a user of a mobile device moves from a local WiFi hotspot to a mobile network. When this occurs on TCP, a lengthy process starts where every existing connection times out one-by-one and is then re-established on demand. To solve this problem, QUIC includes a connection identifier which uniquely identifies the connection to the server regardless of source. This allows the connection to be re-established simply by sending a packet, which always contains this ID, as the original connection ID will still be valid even if the user's IP address changes.
SMB over QUIC is the future of distributed systems
Good god, I hope not. SMB is a horrible, horrible protocol, and QUIC is only slightly better than the typical "let's reinvent TCP using UDP" attempt.
QUIC solves certain problems, true; that's because it's optimized for different use cases than TCP is. That doesn't mean everything should be switched from TCP to QUIC. And it especially doesn't mean that we should prolong the life of dreadful rubbish like SMB by promoting QUIC as a transport for it.
And, of course, the vast majority of distributed systems don't use SMB, because they're not interested in anything SMB does. Remote filesystems are a niche application, statistically, when the whole of IT is considered.
Biting the hand that feeds IT © 1998–2021