I’ve been on an absolute tear over the last year, reclaiming all my data from public clouds (Dropbox, Box, OneDrive , and Google Drive) and building a robust internal near Cloud Service Provider-level private cloud service in my “lab.”[1]

This initiative was also recently expanded to “reclaim the right to my hardware” as well. This is a concept I seized upon from a YouTube video (below) such that after watching I decided had real merit in line with my current data reclaiming initiatives.

And especially as we’ve entered the world of AI which has turned the hardware world on it’s head and shot hardware prices, especially on RAM, sky high. All of this is also in mix with an escalating approach by hardware makers, making hardware accessorizing and repair a much more difficult if not almost impossible proposition. The “odds are not ever in our favor” as hobbists and hands-on technologists.

“I Need To Test This” (As Always)

I have for years toyed with the thought and idea that after spending decades firmly embedded in the Apple ecosystem that one day, maybe, if the Linux desktop ever matures, I might ditch MacOS for Linux. The above video inspired me that the time to at least test the idea had come.

Enter my internal near CSP-level private cloud.

I didn’t necessarily have to go out and buy a new laptop to test the thesis behind the video. All I needed to do was spin up a Fedora Silverblue instance in my internal “EC2” (Proxmox environment) and send the output to my dual 27″ Asus ProArt 4K monitors connected to my Mac Mini M4. I had never tried to do anything like this before in terms of this level of seamless UX/UI. Was it even possible? There had to be a way.[2]

RDP Has Become King

In the past, the classic method/app for running and accessing a Linux GUI (usually X11-based) was to run VNC. I quickly discovered I was dated as X11 and VNC had officially passed to pretty much retired and “no longer preferred” status, respectively, a number of years ago. And I was quite surprised to find the Linux world has apparently embraced Remote Desktop Protocol (RDP) as the new desktop connectivity standard.

So my path was clear and so were my objectives:

• Setup a virtual Linux environment in my own “EC2” (Proxmox)
• It didn’t have to be the snappiest machine but do try to maximize for power and responsiveness
• Display via RDP on my dual monitors allowing me to…
• Simulate a true desktop UX while not yet sacrificing my day to day MacOS that I needed for productivity and my day job

I would try to centralize all my work in the Linux environment to the extent I could and if I needed something I couldn’t set up in Linux, I still had my current day to day MacOS available to me on the same monitor, keyboard, and mouse. Then… I could just see how running Linux day to day went. No sacrifice or wasted time. “Could this legitimately and completely replace MacOS for day to day?” was the open question and this seemed the best way to solve it with the least amount of hassle or cash outlay for an x86 64-bit Intel/AMD laptop.

“Simply future-testing Linux desktop” turned out to be so much more than I thought. What was at one time a side experiment to just “dink around with Linux in a throw-away VM” allowed me to see I had built something much more powerful and permanent — a consistent desktop with secure connectivity to everything

I Did NOT See This Coming!

But what started out as a “test drive” in my private cloud, morph’d instead into something I had not anticipated. A new power I had not foreseen — a centralized, virtual and ever expandable “laptop” in the cloud: One consistent and ever-present, malleable open source desktop to rule them all.

So no matter where I was logged in and what machine I was using, I could always be on the same desktop, apps, browsers, bookmarks, storage, and compute with this “virtual laptop” VM, the screen merely painted to whatever machine I happened to be using as if Linux were installed natively. The keyboard and monitor in front of me simply was a window into a now-consistent world.

And another cool feature since I was running this in “EC2”:

If I ever needed more RAM? Just dial it up. Same as the cloud. Need more storage? Just dial it up. Software settings — not hardware purchases. I have up to 20TB on the internal NAS. Need a faster processor? Swap out the underlying hardware and restore the existing “virtual laptop” VM image. Near infinite upgradability with almost no effort — the desktop and everything that perpetually goes on inside it lives on (also backed up automagically to the NAS and a 3-2-1 storage approach via Proxmox backup settings).

Suddenly my goal of “a physical Linux laptop” had shifted considerably.[3]

I really can’t tell this virtual Linux desktop isn’t natively installed on whatever machine I’m using.

The “Backing Store”

At the time of this writing, my “EC2” was backed by four (4) Proxmox servers. Two (2) in production with 64gb of memory each and two (2) in test with 16gb of memory each. The production Proxmox servers run AMD Ryzen 7 5825U processors with 8 Cores/16 Threads, Turbo Boosted to 4.50GHz and a AMD Radeon GPU. The test Proxmox servers run Intel Twin Lakes 150 Core i3 CPUs also with integrated GPUs.[4]

I decided to go with the Fedora Silverblue Linux distribution I saw in the video. This is an immutable operating system, which I liked the idea of using. (This would later come back to bite me as I never listed and researched my specific requirements before diving into this and eventually, the immutable operating system would whiplash on me. Stay tuned as this all plays a role in my approach which allowed me to remediate this in no time flat.)

Now to spec the virtual machine on which hardware.

Spec’ing The “Virtual Laptop/Desktop” VM

I did at least purposefully spec what the intended production VM should look like before landing the VM on the underlying hardware. I knew I wanted to end up with at least 16gb of memory for the production instance on a production server.

That meant one of the two (2) production Proxmox servers would be the final destination. While both have two (2) NICs that allow them to touch a dedicated high-speed data storage backbone I built, one was more suited than the other as the primary NIC sits directly on not only the same storage rail but also the same network rail as some internal core services such as internal pfSense firewall and Unifi network management as well as PiHole, etc.

Here’s how I spec’d the VM from a Proxmox perspective:

I believe the specs here are fairly clear, even if you’re not familar with Proxmox. What may need to be called out is the 512gb hard drive, reading through that Hard Disk line.

UPDATE 9/2/2026: After running with this hardware configuration for a while, it became evident the Proxmox GPU was not in play. I was able to get the GPU in play by simply switching the Display from VirtIO-GPU (which one would have thought VirtIO-GPU would have done it) to VirGL-GPU. The difference was immediate and stark. What once seemed like RDP latency — which made remote use of this setup dubious — turned out to be straight-up backend rendering. My CPU was getting pounded. Local access now feels like bare metal, no matter what machine I’m using around the house. I get a consistent UX every time I hop into the Linux In The Cloud cockpit. I’ll be covering this and more in a Part 2 soon.

Notice also I had to bump up to 24GB of memory. I simply have too many windows open to keep this crammed into 16GB of memory even on Linux. Which again proved my starting thesis. Bumping up my memory cost me $0 considering today’s RAM prices. I also increased from 4 cores to 6 cores. Now my hardware consumption looks quite moderate for all I’m running.

The Hard Drive

You may also note the hard drive is hosted on the NAS. That is a purposeful architectural decision and tradeoff.

These 64gb of memory/1TB hard drive Proxmox servers are intended mainly to run smaller comtainers and VMs with smaller hard drive requirements, many of them running small 8GB hard drives. In the case of the target server, PiHole, Unifi Network Controller, Netbird, and other small appliances that run the entire house are running on it.

These smaller appliances are apportioned local storage on that local 1TB hard drive for increased performance. Allocating 512GB for the VM I am building would wipe out half of that 1TB space, not to mention leaving little to no room for expanding that hard drive in the future should I require it. Recall that this was a design goal — the ability to add memory or hard drive space. (If push came to shove, these Proxmox servers could be expanded to 128gb of memory and the SSD hard drive expanded — at quite a cost measured by today’s prices on RAM and SSDs, driven by the AI availability shortages — but it could be done.)

This is where having the NAS on the same network rail comes into play. I’m not taking that much of a performance hit to host the hard drive of this “virtual laptop” VM on the NAS where I can expand storage up to almost 20TB.

Note also the SSD emulation for the NAS hard drive.

The Display

What’s also important to call out is the choice for the display. “VirtIO-GPU” is of course leveraging the GPU of the underlying Proxmox server. That’s going to definitely help performance as well as coloration. But this setting is the key to using RDP to display the monitors — note that’s plural — on whatever screen or screens I happen to be on, whether on a single screen laptop, a laptop with a 2nd portable 15″ 1080p screen (as I have) attached, an iPad, or my Mac Mini M4, equipped with two (2) 27″ Asus ProArt 4K monitors and giving me a rich graphics UX and decent screen real estate.

It’s Experimental “Go Time”!

Once the VM was spec’d and defined, it was time to give ‘er a try from the Mac Mini M4 with dual monitors.

That didn’t initially work out too well using Microsoft’s new Windows app for connecting via RDP on MacOS. I got nothing but immediate 0x204 connectivity errors, no matter what I tried, or what troubleshooting I did that confirmed everything should be fine. (That cost me hours of time. But that’s just where Microsoft’s lack of software engineering “polish” was and seems to be unfortunately but unsurprisingly, really.)

Enter Thincast Remote Desktop for MacOS. Their RDP client, which is free, is industrial strength, and overcame the MacOS Microsoft Window app‘s apparent limitations. The only thing I had to make sure was checked in Thincast was 32-bit coloration.

And whala! I had two machines “connected” to the same monitors. Glorious. From here, it was just setting up equivalent apps or connectivity to functionality I needed in Linux and testing it out. If for some reason, I can’t or couldn’t get to something needed, I’m not really losing any time — which I don’t have a whole lot of right now… I can just keep moving on and figuring it all out as I have snippets of time.

How It’s Going Thus Far

I’m extremely happy to say at this point, there is almost nothing I need to do that I can’t do in Linux that I do in MacOS. That’s quite surprising to be honest, but it’s not only working, but it’s working surprisingly well. The MacOS UI is still a more polished, but Linux GNOME has really come a long way and is acceptable. The GNOME environment is a different experience, but it’s one I can and am getting used to rather quickly. (I’m not a big KDE fan because it’s too much like Windows which I absolutely loathe.)

Fedora Silverblue vs. Fedora Workstation

I was really excited to use an immutable OS with Fedora Silverblue, but alas one requirement I had was being able to do my day job (at CDW) on this VM. That requires Citrix Workspace.

For Fedora, that install needed to be from a tarball as no Flatcar or RPM seemingly exists for Fedora. Which meant spraying files all over /var and /usr space — installs/updates of components outside the clean RPM-OSTree layering model. This all breaks Silverblue‘s immutability.

The beauty of doing all this to this point in my private “EC2” (Proxmox) is that:

I didn’t lose anything I did up to discovering this requirement in Silverblue. If I were to lose the Citrix Workspace requirement, I could just go right back to the Silverblue VM. I just turned that VM off in Proxmox and spun up a new VM.

In the new VM, spec’d the same way, I installed Fedora Workstation 44 and kept going. I had installed only a handful of applications in Silverblue, so a re-install took me far less time than all the time I spent just trying to troubleshoot Microsoft’s weak Windows app for RDP.

And since I’m here discussing this particular use case, needing Citrix Workspace for work, here are some screenshots of that experience. Obviously I can’t show actual applications for my work at CDW running in the Workspace screen, but living inside Linux while working inside a company supported and secure Windows workspace is a huge environmental hurdle conquered (despite Citrix’s antiquted Workspace install that forced my switch from Silverblue to Workstation).

This first screenshot is immediately after a fresh install of Fedora Workstation. I installed Thincast in the Workstation VM and RDP’d into the Silverblue VM to use as a reference for everything I had installed up to that point — making sure I didn’t miss anything. Workstation has the green background and the violet background is the Silverblue window. (So at this point, I’m running MacOS -> Fedora Workstation via RDP, fullscreen -> Fedora Silverblue inside of that via RDP, windowed.)

And of course, my first check before re-installing everything else was making sure Citrix Workspace would work under Workstation, which it did, and there is my “CDW laptop in the secure CDW enclave” window below, running Windows 11.

So now, my experience is MacOS running native on the Mac Mini M4, RDP’d into Fedora Workstation full screen on virtual MacOS desktops, with Citrix emulation to work/Windows 11 inside of Fedora Workstation:

I really couldn’t be happier. I really can’t tell this virtual Linux desktop isn’t natively installed on whatever machine I’m using.

Worldwide, Fast Virtual Desktop Capabilities

“Simply future-testing Linux desktop” turned out to be so much more than I thought. What was at one time a side experiment to just “dink around with Linux in a throw-away VM” allowed me to see I had built something much more powerful and permanent — a consistent desktop with secure connectivity to everything under the hood inside my home: my NASes/data, work, my entire network and all the nodes on it (a lot), all internal appliances, etc. I can access this all from pretty much anywhere in the world (via Netbird) on or with any monitor and keyboard in the world and experience the same desktop, consistent UI and UX every time.

The Proxmox server is running on a 1GB switch right off of the firewall/router, so I’m getting 700mbs speeds directly on that VM. Downloads are practically instant. Anything I’m doing for uploads/downloads are getting incredible speeds. I’m only getting 150mbs via mesh, tops, in my office to my Mac Mini M4 over WiFi.

Even videos play decently on the Linux desktop via RDP on the Mac Mini M4 on the home network. There is “some” audio sputtering, but for YouTube videos, perfectly acceptable.

This is where a “split” if I’m out and about and on a laptop works well. Any high demand audio/video can play natively on the laptop or iPad. Everything else not only can play within the “desktop enclave” of the “virtual laptop” on the home network (again over Netbird) but I’m getting 700mbs of actual bandwidth to the “virtual laptop” from anywhere in the world despite very likely working from < 100mbs internet real-world space (ie. airport lounges, coffee shops, in the air on planes — which I can’t wait to test!, etc.)

No matter where I was logged in and what machine I was using, I could always be on the same desktop, apps, browsers, bookmarks, storage, and compute with this “virtual laptop” VM, the screen merely painted to whatever machine I happened to be using as if Linux were installed natively.

Per Use Case Solutions & Results

I’ll spin up another post on per use case requirements, how they are thus far being implemented and fulfilled, and what level of satisfaction I’m receiving inside the Fedora Workstation UX in various situations (as I listed above). Right now the prospect and ability to eventually make the jump from MacOS to Linux as my primary desktop is looking quite good.

I hope this maybe paints a vision for what can be done and what benefits it brings for the high-end techie user that I really quite frankly simply stumbled into.

Thus far, this stress testing is working out extremely well with side benefits becoming main drivers in ways I hadn’t imagined for anticipated. Two quick examples:

1. This post was originally composed in Obsidian running on the Linux virtual desktop reviewed here, accessible from Mac, iPad, iPhone, and Linux using iCloud sync over a user-space rclone local mount in Linux — as a first use case example.
2. I was on the wife’s laptop last night babysitting Google Photo downloads (getting out of all public storage solutions!) and while waiting on downloads, quickly installed Thincast and logged into my “Laptop In The Cloud” and just kept right on working. It looked and felt exactly like I had Linux installed natively on her Macbook Pro 13″ laptop.

That’s all for now. Stay tuned for Part 2 on Per Use Case Solutions & Results!

Footnotes

1. I say “lab” because it’s very much become production and run that way with a clear delineation between production and dev/test servers/nodes.
2. This entire concept has been available to home labbers via Apache Guacamoule, VNC, and even RDP — the latter two over VPN — for quite a while. But I’m not quite sure this level of UX and UI has been this achievable for a modern Linux desktop that competes with MacOS and even Windows. Maybe I’ve just been “out of it” on this type of initative?!
3. I could still achieve both goals — install a local Linux instance for things I would need local CPU for — videos, etc. But for consistent, D2D access across browser sessions, documents, calendars, note-taking, etc… A singular desktop.
4. I started with an 8GB of memory test version on one of the test Proxmox servers before migrating it to production and 16GB of memory — nothing gets installed in production without going through test first.