DEV Community: prasadkjose

Why I Turned My Portfolio Into a Linux Operating System

prasadkjose — Wed, 29 Apr 2026 22:14:58 +0000

If you want to check out the live demo, please visit https://prasadkjose.com/.

As someone who loves math, I am a big fan of formulas. I appreciate their structure, universality and idempotency. As developers and engineers, we always follow the same formula for our portfolio websites - a hero section, project cards, contact form and repeat. Let me stress here that there is nothing wrong with this tried and tested formula but I had a couple of months of unemployment, a very bored brain and a deep dislike for LeetCode practicing. So, I turned my portfolio into an interactive Linux desktop experience, complete with terminal style commands, distro inspired themes, draggable windows and a project that showcases both my technical skills and kooky personality. Which is why I built and open-sourced - Linux-Portfolio.

The big why

I wanted to work on something which is technically challenging, use my 5 years of software engineering expertise and do more than list my education. I wanted it to be a project. I have been using Linux since as long as I remember. I can go on about the perks of Linux for a long time, especially now that the closed source competitors will charge you monthly for the privilege of using their services. But this is not a blog about Linux. I want you to understand my obsession. I want to create a portfolio that blends software engineering and my favorite OS. The goal was simple: build something that mimics the best software ever built, runs in the browser, and use the patterns I have learnt the last 5 years. So this project became a chance to combine React, TS, StyledComponents, serverless functions, etc into one experience. I believe a portfolio should say something about the person behind it. I wanted mine to reflect my love for Linux and some level of technical depth. So I built one that feels less like a webpage and more like a machine you can explore and interact.

Once I committed to the idea of creating a Linux-themed portfolio, the end goal became clear to me. It had to be interactive, playful, and still practical enough for recruiters who may not want to spend 20 minutes learning Linux or terminal commands just to find my resume. So the project became a balancing act between creativity and usability. I’ll split the following section into two parts. First, I’ll cover my thought process behind the design flow and UX decisions. For you programming nerds, I’ll explain how I approached the technical decisions in the second part.

Designing the Experience

I wanted a desktop-like experience with multiple ways to explore. I wanted a natural flow for different users to interact with the app. Users can click around visually, open windows, navigate like a desktop user, or go full power-user mode through the terminal. Basically:

Casual visitor: clicks icons
Developer visitor: opens terminal
Recruiter: views resume right in app with just one click.
Curious person: gets lost for 45 minutes

One of the most fun parts was developing different Linux-themed UX experiences. I got to play around with colors, feel, and personality. Each distro has its own identity, visual language, and vibe. It’s basically theme switching... but with stronger opinions.

To make the experience feel like a real GUI operating system, the app needed stateful, persistent, draggable, and interactive windows for different apps. The end goal is to open all of my projects like applications inside the OS. That small detail changes the experience dramatically. It feels less like reading content and more like using software.

Now here’s the catch: fun interfaces can become slow interfaces very quickly. So I had to pay close attention to keeping the experience smooth, responsive, and usable across screen sizes. Every design decision had to be followed by deliberate performance considerations. Because if your portfolio app takes 9 seconds to load, users may assume your code does too. Unfair? Maybe. Realistic? Absolutely.

I would really like to list and talk about the tech stack used here and throw in some fancy-sounding technical terms. But I am going to do something different. I will walk though my failures, how I had to fix them, and how I ended up with a half-decent facsimile of the end product that I envisioned.

I started with a typical question that plagues every new and experienced engineer starting a new project. Do I start from scratch? Will I be lesser of an engineer if I get some help? Luckily for me, from working at one of the biggest corporations on the planet, I learned that many products are built on top of others—open source or otherwise. Long story short, I decided to fork an existing open-source project and re-engineer the inner mechanics according to my own patterns. After a long search, I found the wonderful Kali-Linux-Hacker-Portfolio. It fit my need for a minimal, performant framework to serve as a foundation for my portfolio. Full credits to the developer for their excellent work and for making it open source.

Next, I had to decide which features to work on and how to improve it. I looked around the web for ideas, brainstormed with ChatGPT, and explored my favorite distro for inspiration. I ended up with 50+ overwhelming ideas, often conflicting with each other. Each one felt more important than the last. For a moment, I forgot that I had merged thousands of features and fixes in my career, and suddenly I was back to feeling like I was on my first project ever. That’s when reality slapped me with Agile. Why can’t I be agile? I can have Scrum with myself. I love talking to myself.

I had to start with one issue. I meant that literally. I created my first GitHub Issue for my portfolio. It was simply to refactor the main App.tsx file, to follow the basic React component structure. What's the famous saying? A tiny drop of water... You know it. Right? This helped me focus and get started on the right track. Every other idea took a back seat. A clear project lifecycle and methodology started forming in my head.

That's my segue into another issue I often encounter. How do I consistently keep myself motivated to contribute and not let the project rot in my github. The obvious answer seems to be code quality, consistency, and maintainability. There are an overwhelming number of tools for each stage of software SDLC, so I'll make this part tech stack agnostic. I decided to start with the basics:

Linter
Code formatter
Hosting and CI/CD
Version control hooks.
Documentation tool and structure.

I'll list out all specific tools at the end of this blog post. After a month, I became a one-person Agile team. I automated most of the maintenance and deployment noise, so now I can focus mainly on coding and QA. I don't want to dissuade you from setting up a maintainable, scalable project, especially if you are a newbie. My intention was to walk you through the real struggles of an experienced engineer, so you know you’re not alone. Sometimes, working in a team can make you oblivious to the other parts of building software. That's my story of how I set out to build a portfolio website and how I ended up with a lifelong project I can be excited to work on everyday.

Summary:

You do not need to build everything from scratch. Using open source foundations wisely is smart engineering, not cheating. Too many ideas can stall progress. Turning ideas into clear GitHub issues creates momentum. Good engineering habits matter even for solo projects: linting, formatting, CI/CD, hooks, and documentation save time later. Even experienced engineers struggle with scope, decision fatigue, and consistency. That is normal. Don't forget. Something is better than nothing.

TL;DR

Motivation often comes from structure. Consistency comes from struture. Systems beat moods.
Side projects can teach ownership skills that team environments sometimes hide.
A personal project can become more than a portfolio, it can become proof of how you think and build.

Technology Stack-

Keeping Linux Responsive - Taming the OOM Killer with EarlyOOM

prasadkjose — Sat, 01 Nov 2025 22:00:39 +0000

Ready, Aim, Kill. The Linux hitman that decides what to kill. But is it a dud?

Here is another, more accurate analogy. Linux kernel's OOM killer is like a firefighter who shows up after the house is already ashes. I am pretty sure it kills something, but your screen is already grey, system is frozen, and those Ctrl+ALT+Del panic smashing is fruitless.

Findings

How does the linux kernel choose it's target to kill?
Let me quote the original kernel method doc for out_of_memory()

[!cite] Kernal Doc

If we run out of memory, we have the choice between either killing a random task (bad), letting the system crash (worse) OR try to be smart about which process to kill. Note that we don't have to be perfect here, we just have to be good.

It chooses a process based on its badness, a kind of naughty list.
A process is “naughty” if it uses a lot of memory but hasn’t been running long. It’s important to note that it’s not easy to determine which process to kill.

The OOM killer is partial toward root processes, as they’re assumed to be well-behaved. If processes have direct access to any hardware, they’re pushed further down the naughty list.

So why does Linux hang indefinitely when the system runs out of memory?
In theory, the OOM killer should free up space and fix this, but why doesn’t it? I became curious about this and set out to find why Linux’s default OOM killer doesn’t work as expected.

The big why:

It turns out that the OOM killer is called by the kernel as the absolute last resort. It provides no guarantees about the unpredictable state of the system. In reality, the system isn’t truly locked up. It will eventually process the pending tasks, or the OOM killer will finally get enough time to kill a few processes.
So here’s the question I always have when my machine just freezes: Why didn’t the mighty hitman take out a process and unfreeze my system?
It turns out the native OOM killer tries its best to stay away from any processes in userspace.
Do I have 20 Chrome tabs open, devouring my RAM? Yes. Will the OOM killer do anything about it? No.

So here is where the question gets more complicated. On my machine, I expect the OOM killer to terminate a couple of older Chrome tabs. But what about a server? Do you really want to kill your DB and hope that those beautiful schemas remain unaffected?
What about the combustion control system on the International Space Station? What process do we kill there? The last one might have been an hyperbole, but the complexity of the issue remain.

I know some of you are thinking: what about memory swaps? It doesn't really help to allocate half of your SSD as swap memory and wait for the processes to crawl along painfully.

What I needed specifically for my use case was an OOM killer that targets user processes, like those memory hungry Chrome tabs. If you have gotten this far, I'll assume you have also been in this situation. So, without further ado, let me introduce you to Earlyoom, a simple and solid tool that's written in pure C with absolutely no dependencies. You can read about it in detail on their Github.

This is how it works. Earlyoom monitors available memory(both primary and swap) and when user defined thresholds(default is 10%) are reached, it kills the process consuming the most memory.

Earlyoom came out as a winner to me among alternatives like Meta's OOMD for it's simplicity, easy usage and excellent documentation.

Did I forget to mention that it checks the memory 10 times per second? It leaves no chances for a frozen system. Guess how much memory it uses for all this? 2MiB total and almost 90% of it is native c libraries that's shared with other processes.

Summary

Linux's kernel is very robust and plans to act when there is a serious issue. sometimes this might take some time or won't yield the results you expect.
The native OOM killer is built to save your machine or server from many general issues like memory leaks and total collapse.
This is where Earlyoom is effective and gets to work before the kernel has to. It's fast, small and efficient and get the job done.
You can run it as a systemd service on machine startup and access all it's logs with journalctl.
You can set up desktop notifications in GUI to know which process was terminated.

TL;DR

Don't worry if your personal computer has only 4 or 8 GB ram. Use Earlyoom to prevent your system being slow or frozen.
The best solution is the one that acts before you even notice the issue.

Commands to Remember

# Installation - 
sudo apt install earlyoom

# Make sure it's running as a systemd service
sudo systemctl status earlyoom

# If it's not, start it as a systemd service
sudo systemctl enable --now earlyoom

# Check logs
sudo journalctl -u earlyoom | grep <process name/pid or SIGTERM to see terminated process>

# Change threshold from default 10% to 20%, 
# edit /etc/default/earlyoom config file and set line to
EARLYOOM_ARGS="-m 20"

# Set a preferred process to kill over others. 
#EARLYOOM_ARGS="-m 20 --prefer '(^|/)(java|chromium)$'"

# Avoid any critical process like db to be killed by earlyoom
EARLYOOM_ARGS="-m 20--avoid '(^|/)(sql)$' --prefer '(^|/)(java|chromium)$'"

Nerd Score

Coolness: 🔥🔥🔥🔥
Effort: 🔨

Do you prefer the native linux kernel or a different OOM Killer?
Do you have a different strategy to prevent your system from freezing?

DEV Community: prasadkjose

Why I Turned My Portfolio Into a Linux Operating System

The big why

Designing the Experience

Summary:

TL;DR

Technology Stack-

Keeping Linux Responsive - Taming the OOM Killer with EarlyOOM

Findings

Summary

TL;DR

Commands to Remember

Nerd Score

Sources: