As a Network and Server Engineer, I’ve spent my career trying to escape the bloat of Windows. But even after a successful bare-metal Linux install, I hit the “Professional Wall”: I needed my VPNs, I needed my customer remote tools, and most importantly, I needed Microsoft Excel with Macros (VBA).
Usually, this is where you give up and go back to Windows. But then I found WinBoat.
What is WinBoat?
WinBoat isn’t just a Virtual Machine or a simple WINE wrapper. It’s a modern, containerized approach to running Windows applications as if they were native Linux windows.
If you are a professional who loves the Linux terminal but is “stuck” with a few must-have Windows tools, this is the solution you’ve been looking for.
Why WinBoat is an Engineer’s Best Friend:
Experimental USB Passthrough: For those of us who need to plug in console cables or hardware keys, WinBoat (v0.8.0+) now supports USB passthrough.
Automated Setup: Forget manually configuring KVM or XML files. WinBoat uses Docker or Podman to handle the heavy lifting. You pick your specs, and it builds the environment for you.
Native Integration: It doesn’t feel like a clunky VM. The apps appear as native windows on your Linux desktop. You can alt-tab between a Fedora terminal and a Windows Excel sheet seamlessly.
Automatic Filesystem Access: One of the biggest headaches in virtualization is sharing files. WinBoat automatically mounts your Linux home directory into the Windows environment. No more setting up manual Samba shares just to edit a script.
Let’s be honest: I don’t love Windows. I don’t like the bloatware, the telemetry, or the way it feels like it’s fighting me for control. As a Network and Server Engineer, I live in terminals and SSH sessions. Naturally, I decided it was time to move my physical machine to the environment I manage: Linux.
I didn’t just use a Virtual Machine. I grabbed a USB stick, backed up my configs, and went for a physical installation on my laptop. I went head-to-head with Linux Mint and Fedora on bare metal. Here is the funny, weird, and brutal reality of a Network Engineer in the “wild.”
1. The “NVIDIA One-Click” Win
On physical hardware, Linux Mint was a dream. Since I’m not here to play games, I just needed my dual-monitor setup and my UI to be snappy.
The NVIDIA Success: My NVIDIA GPU worked perfectly. Mint’s Driver Manager gave me a “one-click” suggestion for the proprietary driver. One click, and it was settled. Voom! High-resolution terminal windows everywhere.
2. Fedora: The “Upstream” Rush
Then came Fedora. It’s fast, it’s sleek, and it makes you feel like you’re working on a NASA terminal.
The Addiction: I found myself running sudo dnf update every few hours just for that hit of new kernel dopamine.
The Reality: For a Server Engineer, Fedora is amazing because it’s so close to RHEL, but on a laptop, it can be a “learning experience” when a new update changes how your hardware behaves.
3. The Headache: The Keyboard Backlight
Here is the part they don’t tell you in the tutorials. My gaming-grade laptop has a specific Keyboard Backlight controller. On Windows, it’s a simple app. On Linux? It was a nightmare. I spent more time digging through GitHub repos and trying to find the right kernel modules to just turn the lights on than I did setting up my web server. On Mint its working but on Fedora i didnt know why.
4. The Secure Boot Trap
If you’re running an NVIDIA card, Secure Boot is your worst enemy. Linux on a modern laptop takes it to a new level. If you have Secure Boot enabled in your BIOS, you can’t just “install” a driver; you have to prove it’s trusted.The Linux Mint Win: I have to give credit where it’s due—Linux Mint makes Secure Boot easy. During the installation, it asks you to set a temporary password. When you reboot, you just enroll the key (MOK), enter that password, and you’re done. It’s a “one-and-done” process that felt almost as smooth as Windows.
The Fedora/Manual Struggle: In contrast, other distros often leave you in the cold. You find yourself manually generating RSA keys and using mokutil in the terminal just to get your NVIDIA GPU to wake up.
The Conflict: The Linux kernel is locked down. When you install the proprietary NVIDIA drivers, the kernel sees them as “untrusted” code.
The Fix: You either have to disable Secure Boot in the BIOS (which feels like a step backward for security) or go through the “ritual” of creating a MOK (Machine Owner Key) to sign the drivers yourself.
The Symptom: You install the driver, reboot, and… nothing. You’re back to a laggy screen because the kernel refused to load the driver.
The Headache: When you install the proprietary NVIDIA drivers, Linux tries to load a kernel module that isn’t “signed.” If Secure Boot is on, your OS will simply refuse to load the driver, leaving you with a black screen or low resolution.
The Final Boss: The “Working Environment”
This is where the dream hit the wall. As a Network Engineer, my “office” is a mix of customer environments and secure tunnels.
The VPN Gauntlet: My day-to-day requires FortiClient IPSec and GlobalProtect. On Windows, these are stable, “set-it-and-forget-it” tools.
The Linux Struggle: On Linux, getting these specific VPNs to behave with physical hardware—while maintaining split-tunneling and DNS stability—became a second job. I spent more time troubleshooting my own connectivity than I did troubleshooting my customers’ servers.
The Productivity Wall: I quickly realized that Microsoft Excel is a non-negotiable. While LibreOffice is great for basic sheets, my work involves Excel Macros (VBA) for reporting and audits. On Linux, Macros are essentially broken. There is no workaround; if you need VBA, you need native Windows.
The Plot Twist: Moving Back to Windows
I’ll be honest: I’ve moved back to Windows. I don’t love it, but in my line of work, the OS is a tool. When I’m in a high-pressure “Network Down” situation, I can’t be fighting with a VPN client or a keyboard backlight. I need my tools to work 100% of the time.
Final Thoughts
I don’t play games, and I still don’t love Windows, but I’ve learned that for a Network Engineer, the “best” OS is the one that stays out of your way during an outage. Linux is my passion, but Windows is currently my most reliable multi-tool.
Few links i refer for guide during my testing. Yeah, i waste my time for my fun because everything i already backup in cloud before change of OS is being run.
On one hand, I love my Windows setup. It’s where my games are, where my Adobe apps live, and where I feel comfortable. On the other hand, every tutorial I watched for backend web development seemed to scream: “You need Linux.”
I wanted to learn Django, the powerful Python framework, but setting it up natively on Windows felt like swimming upstream.
Then I found the bridge: WSL (Windows Subsystem for Linux).
Step 1: Opening the Portal (Installing WSL)
If you haven’t used WSL yet, it feels a bit like magic. It allows you to run a full Linux terminal directly inside Windows. No rebooting, no lag.
I remember opening PowerShell and typing the command that started it all:
wsl –install
My first project wasn’t anything fancy—just a simple blog backend—but the setup taught me more than the code did.
One of the first hurdles was realizing that Ubuntu comes with Python, but usually not the pip (package installer) setup you need immediately. I learned the hard way that you should never mess with the system Python.
I learned the golden rule of Python development: Always use a Virtual Environment.
Seeing that little (my_first_project_env) appear next to my cursor was a small victory. It meant I had a sandbox. I couldn’t break my computer even if I tried.
Step 3: Summoning Django
With the environment active, installing Django was a breeze.
Bash
pip install django
Then came the moment of truth. I navigated to my project folder and ran the command to start the project. This is where WSL shines—the file system integration. I could code in VS Code on Windows, while the code actually ran inside the Ubuntu terminal.
I typed:
Bash
django-admin startproject myblog
cd myblog
python3 manage.py runserver
I switched to my browser (Chrome on Windows) and typed in localhost:8000.
The “It Worked!” Moment
If you’ve ever learned Django, you know the screen. The little rocket ship. The text saying “The install worked successfully! Congratulations!”
A Side Note: The “One Click Settle” Envy (Laravel Herd)
While I am proud of learning the command line, I have to admit—sometimes I look at the PHP world with a bit of jealousy.
After finishing my Django setup, I discovered Laravel Herd. If you are into the PHP/Laravel ecosystem, you don’t even need to touch the terminal to get started. It’s basically a “one click settle” solution. You install it, and boom—you have a fast, native development environment ready to go. No sudo apt update, no configuring ports, just instant coding.
It made me realize how diverse the dev world is.
WSL is for when you want to understand the engine, get your hands dirty with Linux, and have full control over your Python/Django environment.
Laravel Herd is for when you just want to drive the car without opening the hood.
Both are valid, but for my Python journey, taking the “scenic route” with WSL gave me confidence that a one-click installer never could.
A firewall is a security system that controls the network traffic entering or leaving a device, server, or network. Its main job is to protect your system from unwanted access, cyberattacks, and malicious activities by allowing only safe and approved connections.
Think of a firewall as a security guard—it checks every “visitor” (data packet) and decides whether to allow or block it based on rules.
Why a Firewall Is Important
Protects Against Unauthorized Access
Firewalls block attackers who try to break into your network or servers.
Filters Malicious Traffic
Suspicious or harmful traffic (viruses, malware, scans) can be stopped before reaching your device.
Controls Network Usage
Admins can define rules to:
Allow or deny specific ports
Limit access to certain websites
Restrict certain apps or services
Maintains Privacy
Firewalls help keep your internal network hidden from the public internet.
I encounter this common issue when taking over support responsibilities for my employer’s customers. Some VMs experience repeated blue-screen errors as known as Blue Screen Of Death (BSOD), and after a quick check, I usually find that they have not been updated for a long time and never reboot for first time installation.
Most unprofessional, i need to rollback, luckily that server is not database and just for application reading.
When setting up a new Windows or Linux virtual machine (VM), most people jump straight into installing software, configuring services, or deploying applications. However, there’s one very common mistake that often gets overlooked:
❗ Not updating the VM before using it.
Whether you’re using Proxmox, VMware, Hyper-V, Nutanix, or any other hypervisor, updating the system should always be the first step after installation.
Why Updating First Is Important
Security Patches
Fresh installations usually come with outdated packages or missing security patches. Leaving these unpatched can expose your VM to vulnerabilities.
System Stability
Updates include important bug fixes that improve the OS stability and performance.
Better Hardware & Driver Support
Hypervisors often rely on updated kernel modules, guest tools, and drivers. Updating ensures better compatibility.
Avoiding Package Conflicts
Installing software before updating can lead to package version conflicts, especially on Linux systems.
