my-ws -- my personal website

Inspired by my love of low-level programming and Unix-like systems (yes, including the ones that aren't Linux), I decided it would be a good idea to have my own, self-hosted, website where I can display some achievements, cool things I've created, some guides, etc., in the hopes that its existence is either useful to me or benefits others in some way.

As previously prefaced, if you're seeing this then you should generally have a good idea of what my website has to offer, but not quite the full story behind how I decided to set it up.

Around 2017, I purchased an Alienware Aurora R7 desktop computer (I know I know, I learned my lesson), complete with an Intel i7 8700 and the legendary GTX 1080 Ti and could not be happier at the time. Though over time I realized that at exactly 10 PM, somewhere deep deep within the pre-configured Windows 10 Operating System it shipped with, it would set the OS' power plan to a custom "Power Saver", which in this particular configuration, set the CPU speed to half of its base processing power, which on an i7 8700, was about 3.2 Ghz => 1.59 Ghz, without the ability to boost higher. For a CPU whose max turbo speed was 4.6 Ghz, this made the pc functionally unusable unless I manually changed the power plan back to "Balanced" or "High Performance", every night. This is just something I had to live with until early 2023 where I got another pc whose quality and performance have left almost nothing to be desired.

Fast forward to May/June of 2026, it made me somewhat upset that I wasn't using the PC for anything, so I figured after 3 years of letting it collect dust I'd finally do something about it. At first I looked everywhere, including having multiple discussions with various AI models, about how to rip out the mechanism that would set the OS' Power Plan to "Power Saver", and every single attempt failed; everything in Window's Task Scheduler looked okay, and surely the omniscient AI models couldn't be mistaken (/s). So after getting fed up with Windows in this regard, not to mention the constant updating, and random background processes that constantly generated unnecessary fan noise, I decided there was only one solution, to nuke the entire OS and replace it with something without any of these issues.

At first I considered installing NetBSD on it, because after taking Advanced Programming in the Unix Environment at Stevens Institute of Technology, we got intimately familiar with the inner workings of that OS -- and as much as I wanted to go through with installing it, NetBSD does not have really any support for NVIDIA's GPUs, and I simply couldn't let one of the best GPUs ever made, the GTX 1080 Ti, sit unutilized. As such, I decided that Debian Linux would be the next best thing, proper first-party drivers and support, not to mention Debian's excellent reputation throughout the years for stability first, and the fact that the at Stevens we generally get a few years of experience with Ubuntu and Debian (if you choose to take Operating Systems), I had made my choice.

After using rufus on Windows to write the Debian 13 OS installer to a USB drive (a reminder that this is something the dd(1) utility can do on any Unix-like system...), I was ready. I inserted the USB drive into my old Alienware desktop, changed the boot order so it would boot from the USB first, and then I selected graphical installation, thinking it would be easier, and was met with an infinite slew of errors, namely:

(debconf:1260): Gtk-WARNING **: 18:29:04.978: cannot open display: :0

Well okay then, lets reboot and try that again, but this time choosing the text-based installation process (which given I'm perfectly comfortable using a terminal, I probably should've done in the first place).
All was going well and good, until I was asked to choose where I wanted to install the OS and ext4 file system. This particular device had an HDD, and a SATA SSD, and only the HDD (and the installer USB itself) were present, and everyone knows that in 2026 you should avoid installing an OS on spinning disks at all costs, so this was somewhat troubling. After digging around a bit, I had realized that in the desktop's UEFI BIOS, the controller for the SSD was set to RAID 0 (despite RAID having never ran on this device at any point), with the option to switch it to AHCI, and upon doing so (and going through the entire installation setup process for a third time now), the SSD appeared! Afterwards, it was smooth sailing thankfully.

Now that the OS itself was installed and I had configured it to my liking, I tested it out by playing Minecraft (which naturally did not go smoothly, such is the way of things; check out my blog post to see why). Which, after the technical difficulties, passed my very un-encompassing test for what I'd constitute as a system that's ready for use, I began thinking I could put my personal website on this -- a notion that I had been toying with since December of last year (2025), but never quite got around to, and since this was summer break, I had nothing but time.

The biggest issue I faced is that, I don't want to dedicate the whole system to my webserver, primarily from a security standpoint. After weighing possible solutions, Docker, Kubernetes, etc., I remembered that I originally wanted to install and use the NetBSD Operating System - so I installed virt-manager, a type 2 hypervisor, and set up a NetBSD virtual machine running in virtualization mode (as opposed to the much slower emulation mode) through KVM/QEMU, allocating only some CPUs and a fraction of memory from the host system. This way if somehow anyone ever found an RCE (remote code execution) with any of the outward facing services, they would be contained within the sandboxed NetBSD environment, leaving me to later configure other services on the host system, such as a NAS (network-attached storage) running ZFS, without (as much!) risk of it being exposed to the internet.

So now that the Operating System (and virtual Operating System!) was configured to my liking, it was time to go about actually setting up my website. I was fortunate enough to know the design I wanted to go for (the Unix-manual page aesthetic), but wasn't quite sure about where to get my domain name, SSL/TLS certificates, etc.

I explored many options, including but not limited to Gandi, Namecheap, GoDaddy, etc., but many of which were relatively expensive (in hindsight), as they usually bundled in a VPS - a virtual private server, for which to host your website and whatnot on, which is something I simply did not need as I wanted to be arbiter of my own data and own as much of website as I could (to fully own all of it, including email/MX records, etc., I believe I'd need to write a check to ICANN for about $200,000 dollars, but I digress).

With all of this in mind, I eventually remembered industry leader Cloudflare, who was able to supply my domain name, and just my domain name, for just about 10 dollars a year! Despite paying for Cloudflare's wide arrange of features, which I'm sure are all great and top tier, the only one I actually take advantage of is their proxy, which, in short, replaces the existing A and AAAA records that I originally configured to point to my home's IP address, with the IPs of a dedicated proxy node somewhere in their infrastructure that handles forward facing requests by taking them, and then sending them to my webserver, which replies to the proxy, which replies to the original request! You can see this if you're on a Unix-like system by running the host(1) command on tshabbic.com -- you should see at least 2 A records and 2 quad-A records, and if you perform a reverse IP look up through in-addr.arpa using a tool such as dig -x <IP>, you should see that these IPs do, in fact, belong to Cloudflare and not me/my network:

;; AUTHORITY SECTION:
21.104.in-addr.arpa.    3600    IN      SOA     cruz.ns.cloudflare.com. dns.cloudflare.com. 2288625502 10000 2400 604800 3600

With my domain name purchased, the rest was simple: using what I was taught in a previous web development course, I'd use Node.js as my webserver, Express as the framework, and Pug (formerly known as Jade) as the html pre-processor, if only because Pug supports inheritance, not unlike object-oriented programming principals, which makes adding new project pages, for example, very easy and straight forward. There was still an issue though, what to do about the SSL/TLS certificates? I cant be presenting an "insecure" website to people! Back when I was searching through static file servers (before I settled on using Node.js), I saw that caddy seemed to automatically handle the TLS/SSL certificates, so I simply downloaded the certificate and key for the (proxied) A/AAAA records and configured Caddy to use them, and suddenly my website had it's own padlock (depending on the browser you're on) in the address bar! However, I mentioned that Caddy is a static file server, and I still use Caddy, so how is it serving the Node.js/Pug generated webpages? Simple! Caddy allows the configuration of a "reverse proxy", i.e., Caddy is open on TCP/IP ports 80 and 443 (HTTP and HTTPS respectively), and any request it receives on those ports is immediately sent to the Node.js server, which is running locally on a port not accessible to the internet, which replies to Caddy, which then sends it back to the requesting client.

Some additional things to note for this project: the entirety of this website has been developed through ssh(1) and scp(1) to make changes and upload files to the NetBSD system remotely, no GUI, no fancy text editor, just remote access and vi(1) (at least it was vi(1) until I got tired of no-syntax highlighting and then installed vim(1)). Furthermore, many technical intricacies such as "what happens when a process running on the host system and the guest system are using the same port?" have been considered and resolved, although how specifically I would rather not disclose for security reasons!

Point your favorite web browser to https://tshabbic.com!

None that I know of! (And if you find any, they are features!)

Jokes aside, please file bug reports by emailing me at [email protected]

This webserver was first deployed on June 7th 2026 and is continuously receiving content additions, code refactors, and bug fixes.

The domain name tshabbic.com was chosen as it is my first initial and last name, truncated to fit the historical 8-character limit on early UNIX systems; a convention that is still common to this day.