Learn Remote Desktop - History, Background & Why You Need It

#Introduction

Every technology is born from a real problem, and remote desktop is no exception. In episode 1 we take a pause from terminal commands to understand why remote desktop exists, who created it, and when the technology we use today was born. This historical understanding is not mere trivia — it explains why VNC behaves the way it does, why RDP is more efficient on low bandwidth, and when you should choose one over the other.

The journey starts in the mainframe era, where terminals were nothing more than green screens without a GUI, continues to the X11 forwarding concept that opened the door to sending GUIs over the network, and then splits into two major currents: VNC, born from AT&T's RFB (Remote Framebuffer) protocol, and RDP, created by Microsoft for Windows. By the end of this episode, you'll have a decision framework for choosing the right tool.

#History and Evolution of Remote Desktop

#From Mainframes to X11 Forwarding

The concept of controlling a computer from a distance has actually existed since the mainframe era of the 1960s-1970s. At that time terminals had no GUI — only text was sent over the network. Problems started when personal computers and workstations introduced graphical interfaces: how do you display and control a GUI from another machine?

X11 (X Window System) answered with network transparency. An X11 program can display itself on another machine's display via forwarding. This model separates the application client from the display server, and became the seed of all remote GUI technologies we know today.

#The Birth of RFB and VNC in the 1990s

In the mid-1990s, researchers at AT&T developed a more radical concept: sending the framebuffer itself — the pixel representation of the entire screen — to another machine. From this came the RFB (Remote Framebuffer Protocol) and its original implementation, called VNC (Virtual Network Computing).

The original AT&T VNC later split into many implementations that are still alive today:

• RealVNC — the commercial continuation of the original code.
• TightVNC — focused on bandwidth efficiency via Tight encoding.
• TigerVNC — a community collaboration focused on performance and modernization.
• x11vnc — an implementation that shares a running X11 display.

The key VNC concept: the server sends the framebuffer (the collection of screen pixels) to the viewer, and the viewer sends keyboard and mouse events back. Simple, cross-platform, and works on any system that can render pixels.

#RDP: Microsoft's Answer

While the open source community popularized VNC, Microsoft built its own protocol: RDP (Remote Desktop Protocol), introduced in the late 1990s with Windows NT. RDP was designed not to send raw pixel representations, but as a bidirectional protocol that separates the presentation and data transfer layers in a more sophisticated way.

RDP introduced the concept of NLA (Network Level Authentication) — authentication happens before the full desktop session is created, making it more secure and resource-efficient. Because it was designed for WAN networks, RDP is far more efficient on low bandwidth than early-generation VNC.

#VNC vs RDP: Architecture Comparison

#Design Philosophy Differences

Now let's compare these two remote desktop giants side by side:

The most fundamental differences are in two things: how the screen is sent and the security philosophy. VNC sends pixels and leaves efficiency up to the encoding mechanism; RDP builds a layered protocol with far more aggressive built-in compression.

ss -tulpn | grep -E ":(5900|3389)"

The ss -tulpn | grep -E ":(5900|3389)" command shows services listening on the two key remote desktop ports. Memorize these two ports — they'll appear in almost every episode of this series.

#Why You Need Remote Desktop

#Real-World Use Cases

There are several scenarios where remote desktop isn't just a convenience, but a necessity:

• Helpdesk and IT support: helping other users troubleshoot GUI problems from a distance.
• Workstation administration: managing many Linux/Windows workstations without having to sit in front of them.
• Headless servers: accessing the desktop of a server that has no physical monitor attached.
• Troubleshooting: seeing directly what's displayed on the screen when an application misbehaves.
• Desktop environment automation: running and testing GUI applications remotely.

#Choosing a Tool Based on Your Needs

No single tool excels in every situation. Here's a selection framework:

• Limited bandwidth and Windows clients → choose RDP.
• Cross-platform and pure open source → choose VNC.
• Access from outside NAT without setup → consider commercial solutions (episode 22).
• Modern GNOME/Wayland desktop → consider GNOME Remote Desktop (episode 18).

linux-cli  +  x11  ->  x11vnc / TigerVNC
windows    +  wan  ->  RDP / mstsc
gNOME      +  wayland ->  GNOME Remote Desktop

#Modern VNC Development

#From One Protocol, Many Implementations

One thing that makes remote desktop history interesting: the RFB protocol born at AT&T didn't develop as a single straight path, but split into many complementary implementations. Each branch carries a different focus — RealVNC pursues the enterprise market, TightVNC optimizes bandwidth, TigerVNC prioritizes performance and modernization, and x11vnc specializes in sharing a running X11 display.

RFB (1990s)  ->  RealVNC, TightVNC, TigerVNC, x11vnc  ->  w0vncserver, GNOME Remote Desktop

#Bridge to the Wayland Era

Development didn't stop at the first generation. As Linux transitions from X11 to Wayland — which you'll examine in episode 17 — modern derivatives emerged, such as w0vncserver from TigerVNC and GNOME Remote Desktop, which adapt to the new architecture. This proves that even though the protocol is three decades old, its ecosystem stays alive and evolves with the platform's direction.

Remembering this history matters for your mindset: when facing a remote desktop problem, don't ask "which tool is the most famous," but "which tool was born from the same need I'm facing." That's the framework you'll use throughout this series.

#Conclusion

Episode 1 showed that remote desktop is an evolutionary answer to an old question: how do humans control a graphical interface from a distance. From text-based mainframes, X11 forwarding, the birth of RFB/VNC by AT&T in the 1990s, to Microsoft's RDP — each brought a design philosophy that determines how it behaves today.

Key takeaways:

• VNC was born from AT&T's RFB protocol; RDP came from Microsoft.
• VNC sends pixel framebuffers; RDP is a bidirectional presentation protocol.
• VNC ports are computed from the display (5900 + display number); RDP is on port 3389.
• RDP is more efficient on low bandwidth; VNC is more cross-platform and open.
• Choose a tool based on your needs: bandwidth, features, and client platform.

In the next episode, episode 2, we'll dissect VNC/RDP architecture and how they work in depth — the server-to-client model in RFB, the role of vncpasswd, encoding mechanisms such as Tight, Hextile, and ZRLE that determine quality and latency, and how NLA works in RDP. See you in the next episode!