It provides a lightweight Linux platform on MacOS with support for Docker and virtualization. But with some tinkering, I discovered that you can mimic the WSL experience on MacOS with OrbStack combined with XQuartz.

Setting up OrbStack and XQuartz for WSL-like experience

As with everything, the first step is to install the required applications: OrbStack and XQuartz on your Mac. Once that’s done, follow these steps:

Setting up XQuartz

1. Open XQuartz
2. Go to XQuartz > Preferences
3. Click the Security tab
4. Check Allow connections from network clients
5. Click OK
6. In the Terminal, enter xhost + to allow connections from any host (this will need to be done on each startup)

Once you’ve set up XQuartz, you can proceed with setting up OrbStack.

Setting up OrbStack

1. Open the OrbStack app
2. Click Machines on the left sidebar
3. Click the + button to create a new machine
4. Choose a distribution (e.g. Fedora) and click Create
5. Open the terminal and run orb shell to start the machine
6. Set the DISPLAY environment variable to host.orb.internal:0 in the Linux terminal
7. Install an application to test the display (e.g. sudo dnf install firefox)
8. Run the application command (e.g. firefox) to launch the application
9. You should see the application window appear on your Mac screen

Notes

• For Flatpak applications, you must run flatpak override --user --share=network --socket=x11 for X11 forwarding to work properly
• Ubuntu, for some reason, takes awhile to do X11 forwarding. So I recommend Fedora or another distribution for faster results.
• Snap applications do not appear to support X11 forwarding out of the box. I have not done any troubleshooting with them, but they may require additional configuration to work properly.

So if you’ve ever wanted an intimate Linux experience on your Mac, OrbStack combined with XQuartz is a great solution. Because having a full-fledged Linux environment is much more enticing than a Docker container, which I was using before and had frustrations with.

And as we continue to grow, I have been investing in furthering our club’s mission. And my first step in this is starting a community-oriented service hosting project. This is what I call ALUG@UCI Community VPS Services, a cloud container provisioning service that allows users to deploy and manage servers remotely.

The Development Process

I started working on ALUG@UCI Community VPS Services in January 2026. I choose to use Python for the backend, and Javascript for the frontend. This is because these languages are considered the ‘entry’ languages; it makes contributions to the project easier for people of all skill levels. It may not be as fast or efficient as other languages, but I believe it’s the right choice for a project like this.

For containers, I chose to use LXD because it provides an efficient way of running and managing containers. It’s lightweight, secure, and easy to use, which fits the goals of this project.

For the backend, I chose to use FastAPI because it’s a fast, yet easy-to-use web framework that supports all the needs of this project, such as asynchronous request handling and dependency injection. We use PyJWT for JWT-based authentication and aiosmtp for sending emails. For managing containers, we used PyLXD, a Python interface for LXD.

For the frontend, I chose to use Javascript because while it may be ‘primitive’ in the scope of modern web development, it’s a language most web developers are familiar with, and with a relatively simple frontend, using TypeScript or React is not urgent.

Challenges

One of the primary challenges I faced was handling PyLXD operations asynchronously. Since PyLXD uses blocking I/O, I had to find a way to make it work with FastAPI’s asynchronous request handling. This involved using asyncio and a custom executor to run PyLXD operations in the background.

Otherwise, most of the challenges I faced were not related to the technology stack itself, but rather to the nature of the project. This is perhaps the biggest project I’ve ever worked on. With around 2,180 lines of code, the project was time-consuming and challenging, especially when dealing with outside circumstances, such as school. Nonetheless, I dedicated as much time as I could and have reached a minimal viable product within four months.

But the most frustrating challenge I faced was getting IPv4 addresses to work for the containers I was creating. On my personal VPS, IPv4 address assignment worked fine, but when using the server UCI ICS lended us, this did not work. It took around a week for us to figure out the problem, but it is perhaps the biggest hurdle I’ve ever faced in a project.

What I Aim To Do

I am planning to host a beta on UCI ICS infrastructure that will allow our members to host services open to all UCI students. Despite there still being room for improvements to be made, such as optimizing the FastAPI backend and improving the frontend dashboard, I am committed to delivering a functional product that meets our members’ needs.

And as with all resources in the universe, we have a finite amount of resources to allocate; this means we won’t be able to provide containers to everyone. But I am hoping that if this endeavor takes off, we can expand our reach and provide more containers to UCI students.

However it ends though, I believe I will have at least provided a platform for UCI students to host their own services.

I have been an avid Linux user since about October 2021, when I was a high school freshman. My transition to it was a combination of several factors: my gaming laptop running Windows 10 constantly running into the dreaded Blue Screen of Death (BSOD) and the Steam Deck (a Linux-powered gaming handheld) being announced. I was familiar with Linux before this, but the idea of switching to it didn’t cross my mind until I got a Raspberry Pi.

I bought a Raspberry Pi 4 starter at my local Best Buy for no reason other than to satisfy my desire for a new toy. It ran Raspberry Pi OS, which is Debian-based, and I learned various Linux commands and utilities. I even got a little experimental, tinkering to run Steam games like Portal 2. Of course, such software ran like molasses on it, but the learning experience alone was part of why I feel in love with Linux.

I continued (hardly) using my gaming laptop with Windows until I built my first PC around five months later. I ran Pop!_OS on it and used Linux exclusively until six months ago when I started dual-booting with Windows for Win32 software development, as well as for games that didn’t work on Linux.

Later on, I got a workstation laptop that has struggled to last through college lectures, so I needed a new laptop that could last me all day. Out of convience, I went to the UCI Bookstore, The Hill, to buy a MacBook Air. I mainly did it because it was convenient for me, and I fully expected to dread using a Mac. Two months using it has proven me wrong though, at least for the most part.

Why I Love Using Mac

I Value a System That Just Works Over Everything

I’d like to mention that part of the reason why I used Linux was out of the appeal of having full control over my system. So why am I using the antithesis to that idea?

Well, being frank, I haven’t taken much advantage of this idea on my workstation. Like it did come in handy from time to time, but otherwise I just used my Linux system as a regular desktop machine. MacOS, despite being more restrictive, is pleasant to use because everything ‘just works’. The moment I unboxed my MacBook Air, I just went through the setup process and got straight to installing my apps.

Linux (and Windows to some extent) often requires you to go out of your way to install software, such as drivers because the trade-off for mass hardware support is fragmentation. With MacOS, because it only supports a limited set of hardware, everything works like it was made for each other.

Because It’s Unix-like, It Feels (Almost) Like Home

The one commonality between MacOS and Linux is they are both Unix-like. When I first used the terminal on MacOS, almost all commands I knew from Linux were usable. So unlike Windows, which tries to reinvent the wheel, I found home with Mac.

Even the system directories were somewhat similar with common Unix directories like /bin and /usr, but they do have differences; /home on Linux would be /Users on MacOS for instance. Nonetheless, the only thing I needed to do to remember the differences was mental compartmentalization.

Application Installation Is Neat

I think the .dmg format is perhaps the best application installation method I’ve used in years. Nothing is more convenient than opening the file, dragging the app to your Applications folder, and having it sitting in your apps available to be launched at any time. I wish other operating systems like Linux would implement similar methods as it would improve the Application installation experience.

The Hardware Quality is Just Nice

From the very moment I started typing and using the trackpad, it felt extremely comfortable to use. My workstation’s primary discomfort was the trackpad, which was why I always carried a bluetooth mouse with me. But the MacBook Air’s trackpad feels hardly like a chore to use.

The lack of fans is also extremely comforting as I do not have to worry about attracting looks in a public area whenever I do an intensive task.

Why I Hate Using Mac

Restrictive System Access

One of the very things I despise about Apple is their closed and restrictive approach to the user experience. Such as limiting your ability to manage the system on a deeper level. I may sound like I’m contradicting myself, but the ability to do such when needed is still a nice touch.

App Distribution is Scary

One of my main main resentments come from how MacOS uses scare tactics on apps that are not ‘notarized’. And even if you ignore them, you need to make an additional several clicks in Settings to be allowed to open such software. On Linux at least, nobody ever tried scaring you into not running a program because it didn’t get reviewed by a central authority. This was perfect for a hobbyist programmer like me who writes software and shares them online.

To get your program ‘notarized’, you have to pay $99 a year to be part of the Apple Developer Program, which I personally do not find to be worth the cost. This means because I can’t get Apple to review my program, anytime I distribute my MacOS software to anyone, they need to endure popups employing scare tactics to even run them!

Unless You Pay, You’re Missing Out On Quite A Bit

One of my biggest frustrations, especially as a developer, is how Apple restricts you from using certain functionality in your programs, unless you enroll in the same aforementioned program. For instance, I was experimenting with Apple’s Virtualization Framework in Swift and I tried to using NAT networking in the program. I was not allowed to do so because Apple did not grant me the ‘entitlement’ to do so. And to get it, I would have to pay $99 a year and request explicit permission from Apple. Even when I forced my program to compile with the entitlement, MacOS didn’t even run it! It was just immediately SIGKILLed by the system.

My Overall Sentiment

MacOS is a pretty Unix-like system that makes you hardly think of what’s going on underneath. You could be doing just about anything on it without giving the system you’re using a second thought. But when a power user like me really needs to get their hands dirty, the limitations of MacOS start to shine bright.

MacOS alone might still be worth getting a Mac for, especially if you value a comprehensive system that feels well put-together. I have come to appreciate these aspects of MacOS, but I do recognize the shortcomings when it comes to some of my needs.

Recently, I’ve been doing a course specialization with IBM on full-stack software development. And I am glad to report that on March 24, 2026, I have completed the first part of the specialization, Introduction to Software Engineering.

I have learned many valuable lessons about how to develop and design software from this course alone, from architecting a program’s design to the various paths a software engineer can take. My hope is that my newfound knowledge can be applied to current and future projects that I work on!

As of this writing, my programming courses are primarily taught in Python, and I found PyCharm to be satisfying to use. It provided deep integration with the language and had a more intuitive user interface (UI) than Visual Studio Code.

But as I tried other JetBrains IDEs for other languages, I started to feel troubled. They all took up around 2-6 GBs of storage for installation alone, and the cache resulting from extensive use of them could take up around the same amount of storage. This was especially problematic on my MacBook Air, which has a limited amount of storage compared to my workstation that has a combined 6 TBs of storage. Besides, load times and responsiveness felt lacking compared to Visual Studio Code and it felt redundant installing different IDEs for different languages.

A couple days ago, I decided to try Visual Studio Code again; I installed all my plugins, including language-related ones and remote development support, and I ended up uninstalling JetBrains Toolbox and other software. Aside from the more sleek UI, there is not much that I miss from JetBrains.

For a fun fact, this blog entry was written completely in Visual Studio Code :)

Here are the photos I took during my hike:

Developing for Windows on MacOS isn’t a huge issue for me; through tools like Wine and mingw-w64, I can always compile and test my software for Windows. The same thing can’t be said for Linux though. I’ve struggled with running cross-compilers for Linux on MacOS, meaning I would have to wait until I got back to my dorm every night. That is until recently…

I discovered Apple’s open-source Docker alternative, Container, which runs lightweight Linux containers on MacOS. It feels somewhat like Windows Subsystem for Linux (WSL), which I have experimented with before on my workstation’s Windows partition. Nonetheless, I still use and prefer a Linux install out of principle; I prefer an operating system that gives me as much control as possible.

Ever since I began using it a few weeks ago, I have found the experience of being able to run Linux on my Mac to be satisfying. Even if it’s not as intimate as using an actual Linux install, I still enjoy the ability to compile software for it and run basic utilities that I miss on my Mac. I have tried virtual machines that I use SSH on, but I found several inconveniences with them: they take up a considerable amount of storage and the inconsistent NAT addresses meant the SSH address was never the same. With Container, I don’t have to worry about either of those, while enjoying the closest-to-home Linux experience on Mac. Here’s a few screenshots I took using an x86_64 Ubuntu container:

My Rust program that reports system information: Running htop in the container: Mandatory fastfetch :)

Hardware Setups

I have two primary setups:

• System76 Adder WS with an RTX 4060
• MacBook Air M4

System76 Adder WS

This is my primary workstation when I’m at my dorm or at home. I run it in a dual-boot setup: CachyOS and Windows 11. I primarily use the former, but I use the latter when I want to do Windows development or need to play specific games.

I went with System76 because I wanted to support Linux-focused OEMs and while I did experience issues initially, I am pretty satisfied with the experience of it. But the main thing holding it back from being my portable device (aside from the bulkiness) is the battery life; it is inadequate for long outings. This influenced my decision to get a MacBook Air, which I will get into.

MacBook Air M4

Midway through my second quarter at UCI, I went to The Hill (the university’s bookstore) to purchase a MacBook Air, primarily out of convenience, but also because I wanted to dip my toes into Apple software development.

After about a month with it as of this writing, I am incredibly satisfied with it. I enjoy the lightweight, portable, and high-quality design of the device. But most importantly, the battery life allows me to get into lectures without having to worry about whether a charging port is nearby.

Primary Software

I use a variety of software for different purposes. I’ll cover different categories of software and explain my reasons.

Browser

I use Brave because I want a Chromium-based browser that is privacy-focused, which is a major concern for me in a world where data is constantly collected.

Integrated Development Environments (IDEs)

I primarily use JetBrains IDEs like PyCharm, Rider, and WebStorm; I enjoy the convenience and the out-of-the-box experience they provide.

I use Xcode on my MacBook Air for Swift development as it is the primary platform for such.

Media Players

My primary music player is AIMP as I like the variety of features and the modularity of it. On my MacOS and Linux setups, this app is what I use Wine primarily for.

When it comes to watching movies and videos, I use mpv; the minimalism compared to VLC makes me find it to be more responsive and performant.

Compilers

I use GCC when compiling applications for Linux and MacOS, but I prefer to use MSVC when compiling for Windows. I do use mingw-w64 on MacOS to compile for Windows if I do not have immediate access to my primary workstation.

Package Managers

On my CachyOS installation on my primary workstation, I use pacman and paru (an Arch User Repository (AUR) helper) as it’s what Arch Linux, the base of CachyOS, uses. I occasionally use Flatpak for apps that are distributed exclusively in that format. On my Windows partition, I like use WinGet as it’s the primary package manager on Windows.

The same can be said for Homebrew on my MacBook; it provides that Linux-esque method of installing and updating packages on MacOS.

Closing Thoughts

As my first blog post, I think covering my technical lifestyle is a great start. In the future, I plan to write about various topics, from mundane aspects of life to my personal achievements. Stay tuned!