When the industry talks about a "Custom OS," the conversation usually degrades into amateur territory: lightweight Linux forks, registry tweakers, or simple PowerShell scripts executed in Ring-3 user mode to disable a few telemetry services. That is not engineering. That is putting a band-aid on a fundamentally bloated architecture.
At Udayaan Tech, our founding engineering team—Divyansh Singh, Vartika Singh, Aayan Maji, Priti Pal, Sonu Raj Sahu, and Himang Panchal—set out to solve a much deeper, systemic issue in modern desktop computing. We didn't want to just "clean up" an operating system. We wanted to fundamentally restructure the NT Kernel's scheduling behavior and hardware abstraction layer.
To achieve this, we built Kryxus OS: India’s First Application-Specific OS Compiler.
This is a deep dive into the bare-metal engineering that powers Kryxus, and why standard "debloating" is a massive compromise for power users, competitive gamers, and AI/ML engineers.
The Core Problem: IRQL Bloat and CPU Cache Thrashing
A modern, off-the-shelf operating system is a jack-of-all-trades. It has to balance 10,000 different processes simultaneously. It acts as a hypervisor, a print server, a diagnostic reporter, and a gaming machine all at once.
From an engineering perspective, this creates a catastrophic bottleneck at the kernel level. Standard OS environments are heavily bloated with high-IRQL (Interrupt Request Level) hardware interrupts. Because the OS is constantly polling unnecessary background daemons and diagnostic services, the CPU is forced into a state of continuous context-switching.
This leads to:
CPU Cache Thrashing: The L2/L3 cache is constantly overwritten by useless background tasks.
Page Fault Spikes: Excessive virtual memory paging due to bloated memory allocation.
Massive DPC Latency: Deferred Procedure Calls (DPCs) and Interrupt Service Routines (ISRs) queue up, causing microscopic stalls in the CPU cycle.
For the average user, this goes unnoticed. For a competitive gamer relying on 1% low frame-pacing, or an AI/ML developer relying on raw CUDA memory bandwidth, this overhead is absolutely unacceptable.
The Kryxus Architecture: An Offline Environment Compiler
Kryxus operates on a completely different paradigm. Rather than attempting to "tweak" a live, running system, Kryxus acts as a Just-In-Time (JIT) offline environment compiler.
Instead of operating in Ring-3 user mode, our compiler directly interfaces with the Windows Component-Based Servicing (CBS) registry and the Win32 subsystem. By intercepting the OS deployment pipeline at the .WIM / .ESD (Windows Imaging Format) level, we are able to execute byte-level stripping before the OS is even constructed on the target drive.
We surgically unpack the native image, strip out the telemetry daemons, obliterate background hypervisor hooks, and inject bare-metal hardware drivers. We then recompile the image into a highly rigid, bootable state.
Breaking the Compromise: Workload-Specific Re-Engineering
Because Kryxus is an Application-Specific OS Compiler, it does not apply a generic "one-size-fits-all" solution. It reconstructs the OS architecture to perfectly match the user's workload.
The Gaming Profile (Absolute Minimum DPC)
When compiling an environment for gaming, Kryxus physically strips out virtualization (Hyper-V/VBS) and server-level background tasks. We aggressively strip the Hardware Abstraction Layer (HAL) down to its absolute minimum viable state. This forces the NT Kernel to process primary foreground threads with absolute, uncontested priority. The result is a mathematically optimized interrupt queue, dropping DPC latency to near-zero and eliminating micro-stutters.The AI/ML Training Profile (Raw Memory Allocation)
Conversely, an AI developer needs virtualization intact (for Docker and WSL2). Instead of breaking these features, the compiler intelligently targets graphics overhead and native telemetry, prioritizing CUDA and Tensor core memory allocation directly within the kernel scheduler. The OS stops fighting the GPU for resources.The Development/Production Profile (Uncompromised Stability)
For heavy I/O operations (video editing, compiling codebases), the OS is structured to prioritize sequential disk reads and RAM cache retention, preventing the system from prematurely dumping active project files into the pagefile.
Zero Telemetry. Absolute Hardware Privacy.
Because our compilation happens completely offline, Kryxus OS environments are generated with a strict Zero Telemetry Architecture.
We do not just "disable" diagnostic tracking in the registry. The binary executables responsible for phoning home are completely removed from the compiled image. What runs on your hardware, stays on your hardware. There is zero background data collection, zero targeted advertising IDs, and zero forced background updates interrupting your workflow.
The Future of Desktop Engineering
Building India’s first custom OS compiler has been a massive engineering undertaking. It required a complete disregard for standard conventions and a relentless pursuit of hardware efficiency.
The Udayaan Tech team is finally ready to open the doors to the public. If you are an engineer, a competitive gamer, or a power user who demands absolute, uncompromised bare-metal performance, your operating system is ready.
Secure your spot in the Beta Program today at: kryxus.sbs
Engineered in India. Compiled for the World. Powered by Udayaan Tech.
Top comments (1)
the workload profiles are a useful way to frame the tradeoff. i would publish before and after data for the same hardware, with dpc latency, frame time percentiles, compile time, gpu throughput, boot time, and failed driver installs. an offline image builder also needs a rollback path and a compatibility test for updates, security features, docker, and wsl. those checks would help separate measured gains from profile specific side effects.