I forced EVERYONE to use Linux
Based on NetworkChuck's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
A single Linux terminal server can host multiple isolated user sessions so multiple editors can work simultaneously without blocking each other.
Briefing
A single, high-powered Linux machine can replace a whole fleet of individual PCs by acting as a terminal server—letting multiple employees work at the same time from low-cost “thin clients” like Raspberry Pi. The practical payoff is immediate: video editors and 3D artists can run demanding apps (Blender, rendering, editing) in isolated sessions while sharing the same server hardware, avoiding the bottleneck of one-person-at-a-time access on a single workstation.
The setup starts with a real workplace problem: a render/editing machine running Windows 11 can’t support multiple simultaneous users, so one editor blocks another, and remote desktop attempts still collide with local use. The proposed fix is to treat the render machine like a server and move each person’s desktop into its own session. Thin clients—small, inexpensive devices—become the endpoints, while the heavy lifting happens on the central server.
Terminal services aren’t new, and Windows Server has long offered a similar model via Windows Terminal Services, but licensing and server costs make it unattractive for a small team. The workflow here swaps that approach for Linux and uses ThinLinc to deliver the multi-user remote desktop experience “for free” (as described), including support for up to 10 users on a server under the stated plan. The server side runs Ubuntu 20.04 on an x86 CPU (not ARM), and the client side can be almost anything—Windows, macOS, Linux, or dedicated thin terminals. Each user gets a separate session and storage footprint, so multiple editors can work concurrently without stepping on each other.
Hardware planning is treated as an engineering exercise rather than a guess. ThinLinc itself is described as lightweight (about 100 MB), with per-user profile overhead around 100 KB, while CPU and RAM scale with the type of work. For a “full desktop environment” with typical applications, the guidance given is roughly 150–300 MHz per active user and about 100–200 MB of memory per user for basic tasks, with more needed for heavier workloads.
The most important upgrade comes next: VirtualGL, installed on the server to enable server-side GPU acceleration for OpenGL workloads. Without it, the system falls back to LLVMpipe, a software renderer that uses the CPU; with VirtualGL, the same OpenGL test jumps from ~125–128 FPS to dramatically higher performance (the transcript cites around 1000+ FPS). That GPU handoff is what makes Blender and similar tools feel usable even when the endpoint is a Raspberry Pi.
After ThinLinc and VirtualGL are running, the team tests the model workflow: Mike connects from a Raspberry Pi thin client and builds a 3D model in Blender while another editor works on the same server at the same time. An administrative web console provides system health, user/session management, and the ability to shadow sessions. The result is a centralized, controllable workstation environment—one powerful GPU-backed Linux server powering multiple simultaneous creative sessions, with low-cost clients at the edges.
Cornell Notes
The core idea is to centralize multiple users’ desktops on one powerful Linux server using ThinLinc, then connect from low-power thin clients (even Raspberry Pi). Each employee gets an isolated session, so video editing and Blender work can run concurrently without one user blocking another. Because graphics performance matters, VirtualGL is added to route OpenGL rendering to the server’s GPU; without it, rendering falls back to a software path (LLVMpipe). The setup includes creating Linux user accounts, installing ThinLinc on the server and clients, and configuring VirtualGL as a GPU-accelerated server service. This matters because it turns one workstation into a shared compute platform while keeping user control and monitoring centralized.
How does a terminal server solve the “one person per PC” problem described in the workplace scenario?
Why does the transcript emphasize using VirtualGL after installing ThinLinc?
What hardware constraints are mentioned for the Linux terminal server?
How are user accounts and permissions handled in the described setup?
What does the administrative interface enable once ThinLinc is running?
Review Questions
- What changes when you add VirtualGL to a ThinLinc server, and how does the transcript verify the difference?
- How do thin clients and per-user sessions work together to allow multiple editors to use the same server simultaneously?
- What factors determine how much CPU and RAM a shared terminal server needs for different workloads like Blender versus basic desktop tasks?
Key Points
- 1
A single Linux terminal server can host multiple isolated user sessions so multiple editors can work simultaneously without blocking each other.
- 2
Thin clients (including Raspberry Pi) can act as endpoints while the server handles CPU/GPU-heavy tasks.
- 3
ThinLinc is positioned as a lower-cost alternative to Windows Terminal Services by avoiding Windows Server and terminal licensing costs.
- 4
Server sizing depends on user count and workload type; CPU and RAM requirements scale with active users and application mix.
- 5
VirtualGL is critical for OpenGL performance because it routes rendering to the server GPU instead of using the software renderer LLVMpipe.
- 6
A web-based admin console enables monitoring (load, sessions, users) and operational controls like terminating sessions and shadowing users.
- 7
Centralized session management can also enforce user restrictions through group/application/menu customization.