I recently ran into a problem while I was working on a home lab that I thought was worth sharing. I wanted to run a virtual machine, but my main PC didn’t have enough free storage space, so I decided to install VMware on a different machine on the same local network and set up a Windows 11 Pro virtual machine there.

My plan was to enable Remote Desktop inside the guest OS so I could RDP into the VM from my main computer instead of using the second machine directly. When I attempted to connect using RDP, the connection kept failing. I checked the usual settings: Remote Desktop was turned on in the guest OS, the firewall allowed RDP traffic, and the VM was running with a valid IP address. Since everything inside the guest OS appeared correct, the issue had to lie in the network path between my main PC and the VM.

That led me to research the issue, and I learned about VMware’s network adapter modes: NAT, Host-Only, and Bridged. The VM was using the default NAT adapter. This meant that the VM could reach the internet, but it lived in a private network, so my main computer couldn’t initiate a connection with it. Switching the adapter to Bridged mode fixed the problem immediately.

The diagrams below show how each network mode works, along with explanations as to why the network mode choice matters more than it first appears.

How VMware connects a VM to a network

A VM's network adapter is a software device, but VMware presents it to the guest OS like a physical NIC. That virtual adapter still needs to connect to a network on the host, and VMware does this with virtual switches.

In a typical VMware Workstation install, three virtual networks are created automatically:

• VMnet0 - used for Bridged mode

• VMnet1 - used for Host-Only mode

• VMnet8 - used for NAT mode

Your VM connects to one of these virtual switches (or a custom network you create). The network mode choice decides which systems the VM can talk to and whether the VM behaves like another device on your LAN or stays isolated behind the host.

NAT: internet access through the host

NAT is the default for new VMs. It's a good fit when the guest needs outbound internet access but doesn't need to be directly reachable from other devices on your physical network.

In NAT mode, VMware connects the VM to a private virtual switch, usually VMnet8. In my setup, the physical home network is 192.168.1.0/24 and the host has 192.168.1.10. VMware creates a separate subnet for the NAT network, 192.168.150.0/24, and hands out addresses in that range via a virtual DHCP server. A virtual NAT device sits between the VM network and the host's physical connection.

When the VM sends traffic to the internet, the NAT device rewrites the source address so the traffic looks like it's coming from the host. It's the same idea as a home router letting multiple devices share one public IP. This allows the guest OS to have internet access with almost no configuration.

The catch is that devices on your physical LAN can't normally initiate connections to the VM. The VM's 192.168.150.x address lives on VMware's private network and isn't routed across your LAN. So another computer on 192.168.1.0/24 can't just RDP to that address. That's exactly why my Remote Desktop attempt from the main PC failed.

Host-Only: private communication with the host

Host-Only mode also uses a private virtual network, but without a NAT path to the physical network or the internet. VMware creates a virtual switch, typically VMnet1, with its own subnet. In the diagram this is 192.168.100.0/24. The host gets a virtual adapter on the same network, 192.168.100.1, so the host and its VMs can talk directly.

This network mode is useful when VMs need to communicate with the host, or with other VMs on the same Host-Only network, while staying isolated from the physical LAN. It can be used for test environments, security labs, or any scenario where you want to block internet access on purpose.

Host-Only wouldn't have solved my RDP problem. It would have let the VM talk to the machine running VMware, but not to my separate main computer. Since my main PC was another device on the physical LAN, it still wouldn't have had a route into the Host-Only subnet.

A VM with only a Host-Only adapter can't reach the internet, because that network has no route to your physical router or beyond. If you also need internet access, you can add a second virtual network adapter in NAT mode.

The Host-Only adapter handles isolated host‑to‑VM traffic, while the NAT adapter provides outbound internet through the host's physical connection. VMware supports multiple virtual NICs per VM, so this is a common setup for labs and testing.

Bridged: direct access to the local network

Bridged mode was the right choice for my situation. Instead of creating a separate private subnet, VMware uses VMnet0 to bridge the VM's virtual adapter to the host's physical network adapter. The VM then talks directly to the same router the host uses.

In the example shown, the VM asks the router's DHCP server for an IP address and gets one on the 192.168.1.0/24 network. It now sits on the LAN alongside the host and other devices. The VM has its own MAC address and IP address, and other machines treat it like any other physical device.

That’s why Remote Desktop worked once I switched to Bridged mode. My main computer could open an RDP session straight to the VM's LAN address, just as it would connect to any other machine on the same network.

Comparison of the three network modes

Resolving the RDP issue

Once the network modes made sense, fixing the issue was straightforward. I opened the VM's network settings and switched the adapter from NAT to Bridged. The VM picked up a new IP address from the router's DHCP pool and became visible to the rest of the local network. After entering that new IP address into Remote Desktop on my main PC, the connection was successful.

Nothing was broken in VMware or Remote Desktop. NAT was doing exactly what it's supposed to do: provide outbound connectivity while keeping the guest OS on a separate private network. The issue was my use case. I needed another device on the LAN to initiate a connection to the VM, and Bridged mode was the right choice because it made the VM directly reachable as a device on the same physical network.

Conclusion

It is important to choose the right network mode for your use case. Here is a brief description of when to use which network mode:

• Use NAT when the VM mainly needs internet access (updates, browsing, downloads) and no other device needs to connect to it directly.

• Use Host-Only when you want an isolated environment where communication is limited to the VMware host and other VMs on the same private network. Add a second NAT adapter if the VM also needs internet access.

• Use Bridged when other devices on the physical LAN need to access the VM directly. Think Remote Desktop, hosting a service, or testing a machine that should behave like an independent device on the network.

The full project, including the source code, screenshots, and the two documents referenced below, is available on GitLab: gitlab.com/Arnav-Salian/CO3201

Two documents in that repository are worth linking directly, in case you want more detail than this post covers:

• Dissertation (PDF) - the full write-up, around 85 pages, covering everything from background research to final results.

• Re-Evaluation Report (PDF) - a follow-up report covering a correction made to the test data after submission, discussed further below.

This post summarises what the project was, what I built, and what I took away from it, without the length or formality of the dissertation itself.

The problem

For my CO3201 Computer Science Project at the University of Leicester, I built a system to automate university accommodation allocation. At most universities, this process is still handled manually: staff work through applications by hand, matching students to rooms based on preferences and policy rules. During peak admission periods, when hundreds of applications are submitted at once, this becomes slow and error-prone, and students are often left with little visibility into the status of their application.

The aim was to replace that process with an automated, rules-based system that remains fair and auditable, rather than a black-box algorithm that can't be explained or reviewed.

What I built

The system, which I called LeicesterHalls, is a full-stack, cloud-hosted web application consisting of two separate React applications and a serverless backend running entirely on AWS.

• Client application: the student-facing side. Students can register, browse accommodation, submit an application with ranked preferences, track their application status, accept or decline room offers, make payments through PayPal, and view their contract.

• Admin application: the interface for accommodation staff. Admins can manage room inventory, trigger allocation runs, override allocation decisions, handle room change and termination requests, and monitor occupancy and revenue through dashboards.

Both applications call the same backend API, but each has its own authentication and authorization setup, so they had to be designed and secured largely independently despite sharing infrastructure.

The stack, briefly:

• Frontend: React.js with Vite, MUI Joy UI, Axios, AWS Amplify for authentication, and PayPal's Checkout SDK for payments.

• Backend: Node.js Lambda functions behind a single API Gateway REST API, with shared dependencies packaged as Lambda Layers.

• Data: DynamoDB with on-demand capacity, so the database scales without needing traffic to be estimated in advance.

• Auth: Two separate Cognito User Pools, one for students and one for admins.

• Infrastructure: A custom VPC, EC2 instances in Auto Scaling Groups behind Application Load Balancers, Route 53 for DNS, and ACM certificates so both applications run over HTTPS.

How traffic flows through the system

This was the part of the project that took the most iteration, since it involved getting a number of AWS services to work together correctly. The diagram below is the architecture diagram from the dissertation:

Loading the page. A request to the client app or the admin app reaches Route 53 first, which resolves the domain and routes it to the correct Application Load Balancer, since each application has its own. The ALB terminates TLS using the relevant ACM certificate, then forwards the request over HTTP to a healthy EC2 instance in its Auto Scaling Group. Both Auto Scaling Groups span two Availability Zones, eu-west-2a and eu-west-2b, so the system continues to operate if one zone becomes unavailable. Each EC2 instance runs nginx and serves the static React build, which is pulled from an S3 bucket by a user data script when the instance launches.

Making API calls. Once the application has loaded, any user action, whether that's logging in, submitting an application, or loading a dashboard, is sent to API Gateway. Protected routes require a JWT access token in the request header, which API Gateway validates against one of three Cognito authorizers: one for students, one for admins, and a shared authorizer for endpoints both roles can access. Requests with an invalid or missing token are rejected before they reach any backend logic.

Processing the request. Once a request passes the authorizer, API Gateway forwards it to the relevant Lambda function using proxy integration. That function executes the business logic, whether that's reading room data, running the allocation algorithm, or writing a new application, and interacts with DynamoDB using IAM permissions scoped to exactly what it needs. The response is returned through API Gateway to the browser, and each function writes its logs to its own CloudWatch log group, which proved useful throughout development when debugging permission issues.

Authentication follows a similar but separate flow. Registration triggers a PreSignUp Lambda function that checks the student ID and date of birth against a Students table before Cognito creates the account, which prevents unauthorised sign-ups. After email verification, a PostConfirm Lambda writes the corresponding user record to DynamoDB. On login, Cognito returns ID, access, and refresh tokens, which are stored client-side and used to authenticate subsequent requests.

The allocation algorithm

This was the core of the project; everything else exists to support it. When an admin triggers an allocation run for an academic year, a Lambda function retrieves every submitted application and every available room, then runs a policy-constrained greedy assignment algorithm.

Students are processed in priority order: accessibility requirements first, then course type, then submission timestamp. For each student, the algorithm attempts to match them to their highest-ranked accommodation and room choice, out of up to four ranked preferences, provided it satisfies hard constraints such as gender policy, budget, and accessibility requirements. If none of their ranked choices are available, a fallback allocation is made based on the student's stated secondary priorities. Students who cannot be matched under any condition are recorded as unallocated for manual review. Every allocation, offer, occupancy update, and notification is written atomically using DynamoDB transactions, so no partial updates occur.

I chose a greedy, priority-respecting approach over something like Gale-Shapley stable matching, because stable matching doesn't handle hard eligibility constraints well: a room that fails a student's accessibility requirement isn't a valid match regardless of ranking. The definition of fairness I used instead was more direct: no student should be able to point to a room they preferred and were eligible for that was given to a lower-priority student.

Testing it

To evaluate the allocation logic, I built a synthetic dataset of 51 student applications against 234 available rooms for the 2026/2027 academic year, written manually rather than generated randomly, to keep the mix of preferences, budgets, and accessibility needs realistic. Running this through the system produced:

• 94.1% allocation rate (48 of 51 students successfully allocated)

• 87.5% of allocated students received one of their ranked preferences

• 54.2% received their first choice

Running the same dataset through the allocation process twice produced identical results, which mattered given the intent of the system: consistency, not variability, is a requirement for a fairness-sensitive process.

I also stress-tested the infrastructure directly. After SSHing into the EC2 instances, I installed the stress tool and ran stress --cpu 2 to push CPU utilisation to 100%. Once utilisation crossed the 60% threshold configured on the scaling policy, both Auto Scaling Groups provisioned an additional instance each, and the load balancer correctly distributed traffic between the original and new instances.

Finding a bug after submission

After submitting the dissertation, I reviewed the test data again and found an error in the synthetic room dataset that had affected the allocation results reported above.

Each room record includes a RoomInfoID field linking it to an entry in its accommodation's list of room types, such as Single Ensuite, Studio Room, or Adapted Single Ensuite. In the seed data I had built, every room in every flat had been assigned the first RoomInfoID in that list rather than the one matching its actual room type. Because Adapted Single Ensuite happened to be listed first for several accommodations, most of the 234 rooms in the dataset were effectively mislabelled as accessible rooms, regardless of what they actually were.

This produced two failure modes. Because the algorithm correctly restricts accessible rooms to students who have declared an accessibility requirement, the majority of the room pool was incorrectly excluded from non-accessible students, forcing fallback allocations. Separately, students who had ranked a specific room type, a Studio Room, for example, could never be matched to it, because the system had recorded that room under the wrong type. Neither issue was a fault in the algorithm; it behaved exactly as designed against incorrect input data.

I corrected the room type labels in a new dataset (Rooms_Patched.json), without modifying the algorithm or any backend code, and reran the same 51 applications against the same 234 rooms:

With correct room type data, every student was successfully allocated, no fallback allocations were required, and 88.2% received their first choice. Re-running the corrected dataset produced identical results again, consistent with the determinism claimed in the dissertation.

I wrote this up as a formal re-evaluation report to make sure the correction and its impact on the results were clearly documented. It's also a useful reminder that a single incorrect field in seed data can affect an entire set of results without being obvious from the output alone.

What I would do differently

A few limitations are worth acknowledging. 51 applications is enough to demonstrate that the logic functions correctly, but it is far smaller than a real university deployment; the University of Leicester alone manages around 4,600 rooms, so a more representative test would need a substantially larger dataset, ideally generated programmatically rather than by hand. Contracts and invoices are currently generated client-side as PDFs on demand, which reduces storage costs but means no server-side copy exists unless the student downloads it. The PayPal client ID and secret are also currently stored as Lambda environment variables rather than in a dedicated secrets manager, which would be the more appropriate approach for a production deployment.

Given the chance to start over, I would build automated test data generation in from the outset rather than adding it later, which would likely have caught the RoomInfoID error before it reached a submitted result. I would also spend more time analysing DynamoDB access patterns before finalising the schema; the denormalised structure was adequate for a project of this scope but became harder to manage as more tables and relationships were introduced.

Beyond the technical work, this project extended further than anything I had built in previous coursework. I had some prior experience with React and a general familiarity with AWS, but had not previously combined Cognito, Amplify, Lambda, DynamoDB, PayPal integration, and auto-scaling infrastructure into a single system. Most of what I learned came from debugging integration issues rather than from building new features; getting IAM roles and Cognito authorizers configured consistently across different endpoints took considerably longer than expected, and was also where I gained the most practical understanding of how cloud security is actually implemented.

Conclusion

The project achieved what it set out to do. It is a working, deployed system that takes students through the full accommodation process, from application through to allocation, contract signing, and payment, running on cloud infrastructure that scales as intended. The version submitted for assessment reported a 94.1% allocation rate; after identifying and correcting the room data error, the corrected figures show a 100% allocation rate with 88.2% of students receiving their first choice, a more accurate reflection of the algorithm's actual performance. Infrastructure testing also confirmed that the scaling configuration behaves correctly under load.

A few things would need to happen before this system could realistically go into production: testing at a larger scale with a properly validated dataset, and possibly letting students rank more than four preferences to improve preference match rates in a larger deployment. As a final year project, however, it met its original aims: a system that is fair, scalable, and usable by both students and staff, rather than a proof of concept alone.

The full project is available on GitLab: gitlab.com/Arnav-Salian/CO3201

Google Chrome is not just a browser, it is also deeply tied into Google's wider data collection and advertising ecosystem. So I started looking for something that kept the usability of Chrome without all of Google's proprietary services, background data collection, and tight integration with its advertising platform.

The obvious first stop was Firefox. It is the browser most people have heard of first, largely because it has been around for a long time and has consistently positioned itself as an alternative to Chrome. On paper, it makes sense as a recommendation because it is open source, developed by a non-profit organisation, and explicitly focused on user privacy and transparency.

But after actually using it day to day, a few things put me off. A fresh Firefox install comes with sponsored content on the new tab page, which already feels like the wrong direction for a privacy-focused browser. On top of that, Mozilla's 2024 policy changes caused a lot of backlash and raised trust concerns for many users. Then there is the practical side: some sites still work better on Chromium, and a lot of the extensions I relied on simply were not available in the Firefox add-on ecosystem.

That led me toward Chromium-based alternatives. Chromium, unlike Google Chrome, is the open-source project underneath the browser. It gives you the compatibility, extension support, and site reliability of Chrome, but without Google's telemetry, account integration, and ad-targeting infrastructure layered on top.

The Privacy Browser Landscape

After looking through privacy-focused browsers, two options stood out as bloat-free and worth paying attention to:

• Brave Origin, a stripped-down version of Brave built around privacy and minimalism.

• Waterfox, a Firefox-based browser for people who still want the Gecko engine without depending on Mozilla's standard build.

This post focuses mainly on Brave Origin, with a detailed comparison against Waterfox, since Waterfox has become a genuinely serious privacy option in its own right rather than just a Firefox fork with the telemetry stripped out.

What Brave Origin Is

Brave Origin is a more minimal, privacy-first version of Brave. It keeps the parts of Brave that are actually useful for privacy and browsing, then remove the extras that make the standard Brave browser feel cluttered.

Standard Brave is not bad, but it does come with a lot of stuff I do not want in a browser. That includes Brave Rewards, Brave Wallet, Brave News, Brave Leo, Brave Talk, VPN features, and a handful of other built-in services. A lot of that can be turned off, but I would rather use a browser that does not ship with it in the first place.

Brave Origin removes that extra layer and keeps the core experience. What is left is a cleaner Chromium browser with strong built-in privacy features, Chrome extension support, and avoids unnecessary distractions.

What Brave Origin Keeps

• Brave Shields, Brave's built-in ad and tracker blocker written natively into the browser.

• Fingerprint protections, including Brave's anonymised approach to making browser fingerprinting less reliable.

• Chromium extension support, including the Chrome Web Store.

• Widevine DRM support, which matters if you watch Netflix and other DRM-protected services in the browser.

• Native translation, which is genuinely useful and one of those features you miss once it is gone.

• Split View, for side-by-side browsing in the same window.

• Container support, which is a Firefox-style tab isolation feature for separating sessions, cookies, and storage.

That last point is one of the things I like most about where Brave is heading. Containers are one of the most useful features Firefox has, and seeing Brave bring a similar concept to a Chromium browser is a big plus.

Pricing and Availability

Brave Origin launched as a stable, standalone product in June 2026, separate from the standard Brave browser, with Linux users getting it for free while Windows, macOS, Android, and iOS users pay a one-time $60 fee that covers up to 10 device activations. That pricing model makes sense in context because Brave Origin is being positioned as a stripped-down browser with no ads, no rewards system, and no extra monetisation layer.

On Linux, that makes Brave Origin especially appealing. You get the cleaner Brave experience without paying anything, which is a very strong deal for a browser that is trying to do privacy properly.

Waterfox

Waterfox is an independently developed, Firefox-based browser built entirely around privacy. It runs on Gecko rather than Chromium, strips out Mozilla's telemetry, sponsored content, and Pocket integration, and has recently started shipping meaningful privacy upgrades of its own rather than just trimming what Firefox already ships.

What Waterfox Gets Right

• Zero telemetry by default, with all data collection, crash reporting, and remote experiments disabled and locked at build time.

• Oblivious DNS over HTTPS, which routes DNS queries through a relay so no single party can see both who you are and what you are looking up, a feature most mainstream browsers do not offer out of the box.

• Container tabs enabled by default, unlike Firefox, where the same feature needs an extension.

• Native ad blocking, now built directly into the browser using Brave's open-source adblock-rust engine rather than relying purely on an extension.

• Full Firefox extension support, including access to Mozilla's add-on store.

• Built-in sync and password manager, so tabs, history, bookmarks, and logins carry across devices without a separate tool.

• Native translation, built in for translating pages without needing an extension.

• Split view, for side-by-side browsing in the same window.

• Extension support on Android, which is rare among mobile browsers and lets you run the same privacy extensions you use on desktop.

Waterfox genuinely holds its own against Brave Origin on features. The main practical difference is the underlying engine, Gecko instead of Chromium, which means a handful of sites optimised specifically for Chromium can occasionally behave slightly differently.

Brave Shields vs uBlock Origin

The most important comparison is between Brave Shields (Brave's built-in privacy protection) and uBlock Origin (a powerful ad-blocking extension), since each is the core privacy tool people reach for by default.

The short version is that both are good. Brave Shields is better if you want privacy protections deeply integrated into the browser with almost no setup. uBlock Origin is better if you want maximum control and the flexibility to tune exactly how blocking works.

Brave Origin also supports the uBlock Origin extension, so if you would rather have its filter lists and customisation, you can simply disable Brave Shields and run uBlock Origin instead. The same applies to Waterfox, which ships its own native ad blocker built on Brave's adblock-rust engine, but that can be disabled in settings in favour of uBlock Origin, since Waterfox still supports the full MV2 extension. In practice, both are excellent, and for most people the difference is negligible.

Brave Origin vs Waterfox

This is where the decision becomes pretty simple. Waterfox is the clear pick if you want a fully free, cross-platform browser and you do not mind trading Chromium compatibility for the Gecko engine. Brave Origin is the better all-rounder if you want Chromium compatibility and Brave's specific fingerprinting model, and you either use Linux or are willing to pay for other platforms.

Highly Recommended Extensions

These extensions are available on both Chromium-based and Firefox-based browsers.

• uBlock Origin: An open source ad blocker. On Brave Origin and Waterfox, both of which run their own native ad blocker by default, you can disable that built-in blocker and install uBlock Origin instead if you prefer its filter lists and customisation, since both browsers still support the full extension. On Chromium-based browsers, the full MV2 version is limited to a shrinking set of browsers, while Chrome and other MV3-only browsers are limited to uBlock Origin Lite. On Firefox-based browsers, including Waterfox, the full MV2 version works without any restrictions.

• Popup Blocker (strict): An open source lightweight extension that intercepts and blocks popup windows before they even open, rather than waiting for them to appear. It halts all requests for new windows and lets you permit or deny each one, with multiple requests presented in a list.

YouTube Only

• SponsorBlock: An open source crowdsourced extension that automatically skips sponsor segments in YouTube videos based on community submitted timestamps. It also supports skipping intros, outros, and subscribe reminders.

• Return YouTube Dislike: An open-source extension that returns the YouTube dislike count. After Google removed the public dislike count from YouTube in November 2021, this extension restores it using a combination of scraped dislike stats and estimates extrapolated from extension user data, so you can judge content quality before watching.

Which Browser I Would Use

On Linux, Brave Origin would be the primary browser and Waterfox would be the secondary one. Brave Origin gets the edge mainly because of its Chromium compatibility over Waterfox's Gecko engine, since I still run into the occasional site that behaves better or only works properly on Chromium. Brave Origin left beta and became a stable product in June 2026, so it is now a solid long-term option rather than something to wait on, and it is free on Linux too. I still use Waterfox as my secondary browser because it is fast, respects privacy by default.

On Windows, Waterfox makes more sense as the main browser for most people because Brave Origin costs $60 there while Waterfox is free and comes with almost all the features that Brave Origin has. The main exception is if Chromium-specific site compatibility or Brave's browser-level fingerprinting model matter enough to justify paying for Brave Origin.

On Android, I use Waterfox as my mobile browser of choice because it supports installing extensions on mobile, which is really useful. This means you can run the same extensions listed above, including uBlock Origin and Popup Blocker (strict), directly on your phone. This makes a significant difference to the browsing experience compared to most mobile browsers that offer no extension support at all.

Conclusion

For a long time, Chrome stayed on top because it was the easiest option. That is still true in a narrow sense, but it is no longer true if you care about privacy, open source, and reducing dependence on big tech browsers.

Brave Origin is one of the best Chromium-based options I have found if the goal is to get Chrome-like compatibility without Chrome's downsides, especially on Linux where it is free. Waterfox is also great, and on Windows it is probably the easier recommendation for most people unless Chromium-level compatibility matters to you. Between the two, there is now a very real case for leaving Chrome behind without sacrificing the browsing experience that made people stick with it in the first place.

My machine is nothing special: an 11th Gen Intel Core i5-1135G7, Intel Iris Xe integrated graphics, 8 GB of RAM, and a 512 GB SSD. Not exactly high-end, which made Windows 11’s resource demands feel especially noticeable.

Why I Left Windows 11

The Performance Problem

The most immediate and frustrating issue was RAM usage. On idle, Windows 11 was consuming up to 7 GB of my 8 GB of RAM. On a machine with only 8 GB, that left virtually nothing for actual work. Having a few Chrome tabs open alongside Visual Studio Code was a genuine struggle. Multitasking felt like asking too much of a system that should, by all accounts, be able to handle it.

A Buggy, Fragmented OS

The early 2026 Windows updates made things significantly worse. The January and February 2026 updates introduced a wave of bugs that were widely reported and left unaddressed for far too long. Among the most common were telling Windows to shut down after an update only for it to restart instead, Wi-Fi adapters going missing entirely, black screens during boot, and Notepad failing to open. These problems reflect deeper stability concerns, surfacing across core components in ways that disrupt everyday use.

Beyond the bugs, Windows 11 has a deeper identity crisis with its UI. It is a patchwork of different design languages stitched together across decades. The modern Settings app sits alongside the classic Control Panel from older versions of Windows. The right-click context menu is a prime example of this regression. Microsoft buried the most-used options behind a "Show more options" click, adding an extra step to something you do dozens of times a day. Windows 11 also uses React for parts of its shell UI, and the result is a noticeably sluggish interface that feels resource-heavy for what it is actually doing.

Forced AI Everywhere

Microsoft's aggressive push of Copilot has become impossible to ignore. AI features have been pushed into Notepad, Paint, OneDrive in File Explorer, and seemingly every other corner of the OS whether you want them or not. The introduction of Microsoft Recall, a feature that continuously screenshots your activity, made it clear that Microsoft's priorities lie somewhere other than user privacy.

File Explorer also became increasingly unreliable. Search, one of the most basic OS features, is practically unusable. And if you uninstalled Copilot or OneDrive, neither of which you consented to installing in the first place, there was a real chance a future update would quietly reinstall them. For an OS you pay a licence fee for, shipping it with ads on the installation screen is hard to justify.

Privacy, Telemetry, and Local Accounts

Windows 11 is not open source. You have no visibility into what data is being collected or sent to Microsoft. The gradual removal of the local account option during setup makes this worse. Microsoft wants your account linked, which creates a persistent identity that can be tracked and fingerprinted. Telemetry is on by default and difficult to fully disable. For anyone who cares about privacy and data ownership, this is a dealbreaker.

Lack of Customisation and Character

Windows 11 has a corporate and generic feel to it. It has drifted far from what made Windows enjoyable, the personality it had in the Windows 7 and even Windows 10 era. Yes, there are third-party tools to work around most of these issues, but the fact that this is the default state of a modern operating system is telling. Windows has lost its way.

Why Linux and Why Fedora KDE Plasma

The Case for Linux

When it came to picking an alternative, the choice was between macOS and Linux. For me, it was not a hard decision. I care deeply about open source software: the transparency, the community, the philosophy. Linux ticks every box. No telemetry, no big tech tracking, better privacy by default, and you are in complete control of your system.

Linux also has a dramatically lower memory footprint. The OS itself idles at a fraction of what Windows uses, meaning the majority of your RAM is free for the applications you are actually running. On an 8 GB machine, this difference is significant.

Choosing a Linux Distribution

I had previous experience with Ubuntu, both in a dual-boot setup and at university. But Ubuntu has been drifting in a direction I am not comfortable with, especially with Snap packages being pushed over user preference and a general trajectory that feels too close to Microsoft's approach. I also have issues with GNOME, Ubuntu's default desktop environment. It has a macOS-like user interface that I do not enjoy, and it is less customisable than I would like.

What I wanted was a desktop that felt familiar, something closer to a Windows 10 layout, but with the flexibility to make it truly my own. KDE Plasma was the obvious answer. It is fast, highly customisable, and has a clean, intuitive layout that does not try to reinvent how a desktop should work.

For the distro itself, I wanted something that is bleeding edge but stable, shipping modern software quickly, but not at the cost of reliability. Fedora is exactly that. It ships newer kernels and software than many other distros while still feeling polished and dependable. Fedora also offers an official KDE Plasma spin, which made it a straightforward choice.

Installation

Creating the Bootable USB

Download the Fedora KDE Plasma ISO from the official Fedora website. Use Rufus on Windows to flash it to a USB drive. It is fast, simple, and reliable.

BIOS Configuration

Restart your machine and enter the BIOS, typically by pressing F2, F12, or Delete on boot depending on the manufacturer, or on Windows you can hold Shift while selecting Restart to access the advanced startup menu. Then you need to:

• Disable Secure Boot (Fedora supports it, but turning it off can help avoid potential compatibility issues).

• Move the USB drive to the top of the boot order.

Save and exit. Your machine should then boot from the USB into the Fedora live environment.

Installing to Disk

From the live environment, launch the installer. I chose to install Fedora to the full disk. After two years of dual-booting, I was ready to commit. Select your disk, confirm the partition layout, and proceed. You can also enable disk encryption during this step for added security. During setup, you create a local account, which is a refreshing change from being pushed into an online account.

Once the installation completes, shut down, remove the USB, and boot into your new Fedora installation.

Post-Installation Setup

The first thing to understand is that Linux is not a drop-in replacement for Windows. It is a different operating system with a different ecosystem, just as you would not expect macOS and Windows to be interchangeable. What follows is what I set up to make Fedora work the way I want it to.

System Update

Before anything else, update the system:

sudo dnf upgrade

This pulls in the latest packages, kernel updates, and security patches. It is the first thing worth doing on a fresh install.

Flatpak and Flathub

Fedora supports Flatpak out of the box, but adding Flathub gives you access to a much larger app catalogue:

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

This makes it much easier to install desktop apps in a clean and simple way.

Browser: Brave Origin

I switched to Brave Origin, the privacy-focused browser from Brave. It has been great so far, and I plan to write a comparison of Chrome vs Brave Origin in a future post.

curl -fsS https://dl.brave.com/install.sh | FLAVOR=origin CHANNEL=beta sh

Office Suite: OnlyOffice

Microsoft Office does not run natively on Linux, so I installed OnlyOffice as the closest open source alternative for Word, PowerPoint, and Excel-style work.

flatpak install flathub org.onlyoffice.desktopeditors

It handles Microsoft file formats well and feels familiar enough for day-to-day work.

Email Client: Thunderbird

For email, I installed Thunderbird. It is open source, reliable, and a better replacement for Outlook if you want a desktop email client without the extra Microsoft features and services.

flatpak install flathub org.mozilla.thunderbird_esr

LaTeX: TeX Live Full

Since I like using LaTeX for write-ups, academic writing, and similar work, having a full LaTeX setup was essential. Installing the full TeX Live scheme saves time later because you are much less likely to run into missing package issues when working on documents.

sudo dnf install texlive-scheme-full

Theming: Catppuccin Mocha

One of KDE Plasma's biggest strengths is how deeply you can customise it. I installed the Catppuccin Mocha theme because it looks clean, modern, and gives the desktop more personality.

git clone --depth=1 https://github.com/catppuccin/kde catppuccin-kde && cd catppuccin-kde
./install.sh

Follow the prompts in the install script to apply it to the KDE Plasma desktop.

Code Editor: Zed

I have been using Zed as my primary code editor. It is open source, written in Rust, and feels extremely fast. Startup time is near-instant, it handles files smoothly, and the editing experience feels more lightweight than VS Code. That said, VS Code is still very good and I still use it because of its extension ecosystem. Both are good tools, just with different strengths.

curl -f https://zed.dev/install.sh | sh

Notes: Obsidian

For notes and knowledge management, I installed Obsidian. Obsidian stores everything locally in Markdown files, which fits perfectly with the privacy-first direction of moving to Linux.

flatpak install flathub md.obsidian.Obsidian

Password Manager: Bitwarden

Bitwarden is my password manager of choice. It is open source, cross-platform, and works well across desktop and browser environments.

flatpak install flathub com.bitwarden.desktop

Media Codecs, FFmpeg, and VLC

Fedora does not ship with some proprietary media codecs by default because of licensing reasons. To get proper multimedia support, I enabled RPM Fusion and installed VLC:

su -
dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
dnf install vlc
dnf install python-vlc

Once RPM Fusion is enabled, you can also install FFmpeg and other useful multimedia packages.

After the Switch

The difference has been significant. Fedora KDE Plasma has solved most of the problems I was facing with Windows 11.

• RAM usage is dramatically lower, which means there is finally room for actual applications and proper multitasking.

• Everything feels faster and more responsive, from opening apps to browsing files.

• Dolphin, the KDE file manager, is quick and search actually works.

• There is no bloat on install, so the system feels clean from the start.

• Wi-Fi works reliably.

• There is no forced Copilot integration or AI being pushed into basic apps.

• Most updates are straightforward with sudo dnf upgrade && flatpak update, and they rarely require a restart.

• I get a local account, more privacy, no telemetry, and no cloud storage tied directly into the file system.

• Linux takes up less storage space, which leaves more room for applications and personal files.

• KDE Plasma is highly customisable and gives the desktop actual personality.

The switch does require some adjustment. Not every Windows application runs on Linux, and there is a learning curve around package managers, desktop environments, and terminal commands. But for the way I work, which is mostly coding, writing, research, and general productivity, Fedora KDE Plasma handles everything I need without getting in the way.

If you are on a mid-range or older machine being dragged down by Windows 11, Linux is worth serious consideration. Fedora KDE Plasma has been a great fit for me because it feels modern, stable, lightweight, and genuinely enjoyable to use.

Why switch from Google Photos to a self-hosted solution?

Google Photos has long been a convenient solution for storing and managing personal photos and videos. Its seamless integration with the broader Google ecosystem made it difficult for many users to consider alternatives. However, the transition from offering unlimited free storage to adopting a subscription-based model under Google One prompted many - including myself - to reconsider our reliance on traditional cloud storage. With an increasing number of services moving to subscription models, I find this trend inconvenient and unsustainable for long-term use.

Previously, Google Photos offered free unlimited storage for certain formats, but this policy changed with the announcement in November 2020 that unlimited storage would end on June 1, 2021. Since then, concerns have grown over long-term costs, data privacy, and the lack of control over personal media stored on big tech platforms.

While using the Google One plan - 200GB for £2.49/month - is pretty cheap, my decision to leave the service was not driven by cost. It was about regaining control over my data. I no longer believe entrusting my personal photo collection to a large corporation. In my view, our personal media should not be managed by tech giants whose priorities may not always align with user privacy.

So I decided to cancel the Google One subscription and switch to a self-hosted solution. This way, I have full control over my photos and videos, and I can manage the security and privacy myself.

What is Immich and why I chose it over LibrePhotos or PhotoPrism?

Immich is an open source self-hosted photo and video management solution. It lets users easily back up, organize, and manage their photos on their own server. Immich helps users browse, search and organize their photos and videos with ease, without sacrificing their privacy. Explore the live demo [Open Demo].

One of the main reasons I chose Immich was its modern user interface, which the developer intentionally designed to be similar to Google Photos, making it easy for users to get accustomed to. Unlike older alternatives like LibrePhotos or PhotoPrism, Immich focuses on delivering a polished UI, mobile-first syncing, and smooth timeline organization. After testing all three photo management solutions, I found Immich faster and more polished. The mobile app and commitment to active development made it the clear choice for my home lab.

Overview of the switching process

The rest of the article covers the process I followed from planning to completion: preparing my self-hosted environment and setting up Immich. I configured secure local access using Nginx Proxy Manager with SSL for HTTPS, and I plan to enable remote access with secure VPN connection or Tailscale. I also compare the cost, scalability, and privacy of both platforms and share key lessons I learned along the way.

Planning the Switch

Requirements for Hosting Immich

Hosting Immich is quite straightforward - all you need is a server, which is essentially a computer that's always on and provides services, data, and resources to other devices over a network. This server can even be an old laptop you no longer use. For example, if you have a Windows laptop that became slow over time and you replaced it with a new one, you can repurpose the old laptop as a server by installing Ubuntu to improve its performance.

To store your photos and videos, make sure you have sufficient storage capacity; in my case, I use 2 TB of storage. Here are the basic requirements for hosting Immich:

• RAM: Minimum 4GB, recommended 6GB.

• CPU: Minimum 2 cores, recommended 4 cores.

• Persistent storage large enough to hold your entire photo and video library.

• Docker support

• Recommended: A domain name for setting up a reverse proxy with HTTPS.

• Optional: Remote access configured via Tailscale or WireGuard for secure external connections.

Choosing the Right Hardware: NAS or Home Server?

I had two hosting options:

1. NAS (Synology): user-friendly and requires minimal setup, making it ideal for people who want a more hands-off experience. However, it comes with some limitations - if I used Synology, I would be tied to their software ecosystem. While it's possible to install third-party apps, it's not as flexible, and you don't have full control over the system. Switching away from their platform in the future or doing deep customisation can be difficult or even unsupported.

2. Home Server: offers full control and flexibility. I can choose the operating system (like Ubuntu), configure services exactly the way I want, and switch platforms any time. This approach gives me complete freedom to run applications like Immich with Docker, fine-tune performance, and scale or change things as my needs grow.

Ultimately, I chose a home server because it gives me full control over how I host and manage my media.

Setting Up Immich (Linux)

Installing Immich on Docker

The recommended way to install Immich is using Docker and Docker Compose. [Learn More]

1. Create a directory ./immich-app to save the docker-compose.yml and .env files.

   mkdir ./immich-app
   cd ./immich-app
   

2. Download these two files docker-compose.yml and example.env from your browser and move them to the directory that you created, in which case ensure that you rename example.env to .env. (Find latest releases on Immich's GitHub)

3. You can also choose to create the .env file and populate it with custom values.

   # You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables
   
   # The location where your uploaded files are stored
   UPLOAD_LOCATION=./library
   
   # The location where your database files are stored. Network shares are not supported for the database
   DB_DATA_LOCATION=./postgres
   
   # To set a timezone, uncomment the next line and change Etc/UTC to a TZ identifier from this list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
   # TZ=Etc/UTC
   
   # The Immich version to use. You can pin this to a specific version like "v1.71.0"
   IMMICH_VERSION=release
   
   # Connection secret for postgres. You should change it to a random password
   # Please use only the characters `A-Za-z0-9`, without special characters or spaces
   DB_PASSWORD=postgres
   
   # The values below this line do not need to be changed
   ###################################################################################
   DB_USERNAME=postgres
   DB_DATABASE_NAME=immich
   

   • Consider changing DB_PASSWORD to a custom value. Postgres is not publicly exposed, so this password is only used for local authentication. To avoid issues with Docker parsing this value, it is best to use only the characters A-Za-z0-9. pwgen is a handy utility for this.

   • Set your timezone by uncommenting the TZ= line.

4. Edit your docker-compose.yml file to bind the Immich web port to localhost only. Locate the ports section for the immich-server service and change the line from - '2283:2283' to - '127.0.0.1:2283:2283'

   name: immich
   
   services:
     immich-server:
       container_name: immich_server
       image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
       # extends:
       #   file: hwaccel.transcoding.yml
       #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
       volumes:
         # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
         - ${UPLOAD_LOCATION}:/usr/src/app/upload
         - /etc/localtime:/etc/localtime:ro
       env_file:
         - .env
       ports:
         - '127.0.0.1:2283:2283'
       depends_on:
         - redis
         - database
       restart: always
       healthcheck:
         disable: false
   
   # REST OF FILE
   

   This binds 127.0.0.1:2283:2283 in the Docker Compose file, which means the Immich server only listens on the local machine's loopback interface. As a result, it's not accessible directly from other devices on the network. Instead, the Nginx Proxy Manager handles external HTTPS requests to https://photos.local.domain.uk and securely forwards them to Immich on localhost, keeping the server protected behind the reverse proxy while managing SSL and external access.

5. From the directory you created in Step 1 run the following command to start Immich as a background service:

   docker compose up -d
   

Using a Reverse Proxy (Nginx Proxy Manager) with SSL for Local HTTPS

1. Create a directory ./nginx-proxy-manager and inside it, create a docker-compose.yml file with the following configuration. [Learn More]

   services:
     app:
       image: 'jc21/nginx-proxy-manager:latest'
       restart: unless-stopped
       network_mode: "host"
       ports:
         - '80:80'
         - '81:81'
         - '443:443'
       volumes:
         - ./data:/data
         - ./letsencrypt:/etc/letsencrypt
   

2. Run the following command to start Nginx Proxy Manager as a background service:

   docker compose up -d
   

3. When your docker container is running, navigate to http://<your-machine-ip>:81 for the admin interface.

4. Default Admin User:

   Email:    admin@example.com
   Password: changeme
   

   Immediately after logging in with this default user you will be asked to change your details and credentials.

5. Click on Hosts, then select Proxy Hosts, and click the New Proxy Host button. Enter your domain names - you can add multiple if needed. I chose a .local domain because it's only accessible within my local network; for example, I used https://photos.local.arnav.uk. Next, set the Forward Hostname/IP to 127.0.0.1 and the Forward Port to 2283.

   

6. Click on the SSL tab, then enable Force SSL and Use a DNS Challenge. For the DNS provider, choose Cloudflare, and finally, click to agree to the Let's Encrypt Terms of Service.

   

7. In a New Tab go to Cloudflare and Search for API Tokens in the Cloudflare search bar or go directly to dash.cloudflare.com/profile/api-tokens, then click on Create Token.

   

8. Then click on Use Template for Edit zone DNS.

   

9. Then select your domain name from the dropdown.

   

10. Click Create Token

    

11. Copy your API token and save it securely in a safe place for future use.

    

12. Replace the existing API Token with the one you copied from Cloudflare then click Save.

    

13. You should now see Online Status in the Proxy Hosts list.

    

14. Go to DNS Records and click Create New Record. Choose A Record, set the Name to *.local (to cover all subdomains), and enter your machine's IPv4 address as the value. Make sure to set it as DNS only (disable the proxy). To find your machine's IP address, you can run ipconfig on Windows or ip a on Linux/macOS in the terminal. Then click Save.

    

15. You can now access Immich using the domain name you set up - in my case it's https://photos.local.arnav.uk - from any device within your local network, but it won't be accessible from outside your network.

Configuring Users, Partner Sharing, and Mobile App

1. If you have friends or family members who want to use the application as well, you can create additional accounts for them. [Learn More]

2. Immich allows you to share your library with other users. They can then view your library and download the assets. You can manage Partner Sharing from the User Settings page on the web. [Learn More]

3. The mobile app can be downloaded from the following platforms: Google Play Store / Apple App Store / GitHub Releases (APK). [Learn More]

   1. Login to the mobile app using your server's endpoint URL at https://photos.local.domain.uk (replace this with your own domain name).

   2. Navigate to the backup screen and select which album(s) you want to back up to the Immich server.

      

   3. Scroll down to the bottom and press "Start Backup" to start the backup process. This will upload all the assets in the selected albums.

Optional: Setting Up Immich with Tailscale or WireGuard to Access Immich Remotely

[Implementation Pending]

Cost, Privacy, and Scalability

Trade-Offs Between Self-Hosting and Google One Subscription

Google One Subscription Plans: https://one.google.com/about/plans

Review and Conclusion

Understanding Ports, Networking, and Remote Access

Why Self-Hosting Is Worth It for Photos

Despite a few initial challenges, the result is a fully self-hosted, fast, and modern photo management solution. Immich performs as well as - or even better than - Google Photos in many ways. Now that I've successfully set up a self-hosted photo management service, I am ready to explore hosting more services in the future, particularly Nextcloud for file syncing and collaboration and automatic SSD backups for cold storage. Knowing that all my media is fully owned and controlled by me makes the effort completely worthwhile.

Acknowledgement

Some of the content and instructions in this article have been adapted from the official Immich and Nginx Proxy Manager documentation to provide an easy-to-follow explanation and streamline the setup process. Full credit goes to the development teams of both projects for their thorough and helpful resources.

• Immich – for providing an open-source self-hosted photo and video management solution. https://immich.app/

• Nginx Proxy Manager - for reverse proxy with SSL for HTTPS. https://nginxproxymanager.com/

• Docker and Docker Compose - for containerizing and managing the application setup. https://www.docker.com/

The AWS network diagram illustrates the setup of a Virtual Private Cloud (VPC) with public and private subnets in a single Availability Zone (AZ). It includes the creation of EC2 instances, route tables, an Internet Gateway, and a NAT Gateway, ensuring secure communication between the instances within the VPC and external services.

Converting Diagram into AWS Network

Creating Virtual Private Cloud

The IPv4 CIDR block for the VPC was configured as 10.0.0.0/16, which provides 65,536 IP addresses to accommodate the network.

The first VPC shown is the default VPC.

Creating Subnets

The newly created VPC (new-vpc) was selected for subnet creation.

For the first subnet, a PublicSubnet was created in Availability Zone eu-west-2a, with an IPv4 CIDR block of 10.0.0.0/24 (within the VPC CIDR block).

A PrivateSubnet was created in the same Availability Zone (AZ) of eu-west-2a. While it's typically recommended to distribute public and private subnets across different AZs for high availability, a single AZ was used here for simplicity. Since the 10.0.0.0/24 block was already assigned to the PublicSubnet, 10.0.1.0/24 was used for the PrivateSubnet, which still falls within the VPC's CIDR block.

Launching a Public EC2 Instance

A new EC2 instance called PublicInstance was launched, using the default AMI and the t2.micro instance type, which is free-tier eligible.

A new key pair, my-key-pair, was created to allow SSH access to the instance.

The network settings were edited to deploy PublicInstance in the PublicSubnet, assign a public IP, and use the default security group (PublicSecurityGroup).

Creating an Internet Gateway

An Internet Gateway was created and attached to the VPC to enable internet access for public instances.

Creating Route Tables

The default route table allows communication between Public and Private subnets by default, as indicated by the local route.

Explicit subnet associations are required for both the Public and Private Route Tables.

Here, the PublicSubnet was associated with the PublicRouteTable.

Next, the PrivateSubnet was associated with the PrivateRouteTable.

The route tables have been successfully associated with the respective subnets.

Allowing Route to Internet Gateway

A route was added to the PublicRouteTable with 0.0.0.0/0 targeting the Internet Gateway. This allows PublicInstance to connect to the internet.

Connecting via EC2 Instance Connect

The internet connection was tested by running sudo yum update -y, which succeeded, confirming the internet route was working.

Launching a Private EC2 Instance

A new EC2 instance named PrivateInstance was launched with default settings, using the existing my-key-pair key pair for SSH access.

The instance was placed in the PrivateSubnet without a public IP, using the default PrivateSecurityGroup.

Using SCP, the key pair was uploaded to PublicInstance to enable SSH access to the PrivateInstance.

The key pair was successfully uploaded to the PublicInstance.

Access to PrivateInstance was confirmed, since traffic is allowed between the two subnets by default. However, the PrivateInstance does not have internet access.

Attempting to run sudo yum update -y on PrivateInstance failed, since there is no internet access.

Creating a NAT Gateway

A NAT Gateway was created in the PublicSubnet, allowing instances in private subnets to access the internet without allowing external services to initiate connections. The NAT Gateway was allocated an Elastic IP.

Adding Route to NAT Gateway

A route was added in the PrivateRouteTable, setting 0.0.0.0/0 as the destination and the newly created NAT Gateway as the target.

This allows PrivateInstance to access the internet through the NAT Gateway, while external services cannot initiate a connection with it.

Conclusion

This AWS setup provides a solid network architecture with proper segmentation between public and private subnets. By leveraging Network Access Control Lists (NACLs), additional security layers are added to restrict or allow traffic at the subnet level, offering more control over inbound and outbound traffic. This ensures a secure and organised VPC setup with controlled access to and from the internet for both public and private resources.