shub39

Switching to Niri

Fri, 06 Mar 2026 00:00:00 GMT

About 3 years ago, I decided I've had enough of Windows 11s bs and decided to switch to linux. Started with linux mint, got familiar with the terminal and basic linux concepts. Then I moved to fedora and loved it. One day I stumbled upon a subreddit called r/Unixporn. Its a place were linux users customize their desktop environments and share their setups. It really inspired me to explore this thing called Hyprland and build my own setup.

With a goal I switched to Archlinux and configured Hyprland on it. Customised every single detail to my liking and made it truly my own. I even setup a dotfiles repo to keep track of all my changes and have a backup of my setup that I can easily reuse on other machines. Even made a really dramatic youtube video showcasing it lol.

::github{repo="shub39/dotfiles"}

Coming from a desktop environment like cinnamon, the range of options, customisations and animations I had in hyprland was truly amazing. I was really into Fear and Hunger at the time and customized it according to the game's aesthetic. This took a lot of trial and error, but eventually I settled into something that felt just right.

I used this for 2 years, sinking deeper and deeper into the hyprland ecosystem. I was suddenly so fast with computers! Everything I wanted was a keybind away! But somewhere inside me I knew I had to move on. There was this lingering itch in me that I couldn't explain but things needed to change. Maybe its because of the years of using Custom Roms in my phones, The constant anticipation of a new kernel, A new feature update, The desire to try bleeding edge Roms. The thrill of wiping out my phone's data constantly rechecking if I had made a backup or not, The CrDroid boot animation with the creepy eye image animating in my face was a different kind of high. I really missed that feeling. I'll leave this story for another time.

Basically I knew I had to switch sooner or later.

When I discovered Niri I tried to switch to it right away but something felt off, It didn't support multiple config files yet 😭. The system was great. The idea of an infinitely scrolling row of windows was really sitting right with me. But the lack of multiple config files made me put it off for later.

Eventually they added support for it and I made the switch as soon as I could. Its been about a month of using Niri and I really like it! The overview of all my active workspaces and a screenshot utility baked in are really nice. Especially in Android Studio, my workflow has significantly improved. I use a single 27 inch monitor and viewing every part of my workflow was difficult on hyprland. Now I can easily isolate the emulator, the file window, the terminal, the debugger, and all studio stuff in a single workspace and easily scroll/sweep through them. Same for every other application.

I am using Quickshell for the Bar and widgets and while I am still getting used to it, It works really well with Niri. It consumes a bit more RAM than just using rofi and waybar but its infinitely more customizable. I think I'll stick with this for years to come.

Here's a video of me yapping about the switch.

RpiAttendance

Tue, 10 Feb 2026 00:00:00 GMT

::github{repo="shub39/RpiAttendance"}

So I really overdid a college project. I built something that I can proudly show off as proof of my skills.

This was a college project I was handed down from my seniors who did no work on it (and still included it in their resume). I was tasked to make an attendance system that used fingerprint data via an R307 fingerprint scanner connected to a Raspberry Pi. I was very interested in learning about linux and the things possible with it so I took this up eagerly. The only thing I knew about raspberry pi at that time was that it is a small computer that runs linux.

I explored all the possibilities of this device. I was given a Raspberry Pi 4 Model B with 8GB RAM and an 128GB SD Card. I knew some python basics and since python is the only best supported language for raspberry pi at that time, I decided to use it to make a minimal functional prototype of the project. Very rough scripting and some poor architectural decisions (storing data in csv files 😖) were made but it was a demoable prototype.

With that I was encouraged to present this on some college and inter college events and won some awards for it. People seemed really impressed with it but having built this myself, I knew what it really was. A hacked together collection of scripts that will break down in any real-world scenario. I have archived the scripts here.

I was suggested by faculties to add a face recognition system as well with the fingerprint scanner. Being very dissatisfied with my current work I decided to rewrite the entire project from scratch.

At first I decided to rewrite this in python but as I grew more familiar with python I started to hate it more and more. The dependency hellscape and no Types caused annoying runtime crashes. The libraries I was using to Interface with the sensors were all python too. Deep down they were all wrappers around C/C++ libraries and setting them up was a nightmare. The IDEs that can be used on raspberry pi are also very limited. Coming from VSCode and Pycharm, using thonny and geanny on the Pi was like torture. No automatic indentation and the Inconsistent Tabs and Spaces error became a trigger word for me causing an instant crashout followed by depression.

Fortunately, besides this project I was also learning Kotlin and Jetpack Compose. The robust type system and syntax with a powerful yet heavy IDE made me fall in love with Kotlin. As soon as I discovered Kotlin Multiplatform, I knew I had to use it for this project. Kotlin Multiplatform has an llvm backed compiler that generates native code, eliminating the need for a JVM. This made it perfect to compile a binary to run it on the raspberry pi.

There was one problem that I overlooked. The sensor libraries were written in python and there were no KMP bindings I can use. I could have used the underlying C/C++ libraries directly but that would have been a lot of work (maybe I should do it someday). I decided to neatly wrap up all the Python code in a FastAPI server and communicate with it using HTTP requests. I painstakingly tested the API against every possible scenario and made sure to account for all edge cases that can arise in a production environment. The best thing about this approach is that it decouples sensor logic from the main app, making it easier to test, maintain and scale.

The wonderful thing about a type system like kotlin and Rust is that you can write code in such a way that accounts for every possible type of error. Ofcourse doing this is a significant time investment but the peace of mind it provides is absolutely worth it.

After taking care of the sensors I tackled the main server. Decided to use a Kotlin Native server running Ktor and setup a database using ROOM. Yes The Android team has been hard at work porting all the androidx libraries to KMP and as a result you can use ROOM in Kotlin Native!! My first reaction to this information was pure ecstasy.

:::note[What's ROOM?] ROOM is an Android database library that provides an abstraction layer over SQLite, making it easier to work with databases in Android apps. :::

Setup a neat Ktor server with ROOM support to house the main application logic. Its job is to maintain the database and manage the sensors. I also discovered an RPC protocol that can be used with Ktor. With Krpc I decided to make a Compose Multiplatform client to interact with the server as an admin The whole integration was super seamless and I was able to get the app up and running in no time.

The only problem that I faced with Kotlin Native was cross compiling the native binary for Arm64 from my x86_64 machine. I figured out a solution by setting up a CI job that builds the binary in a preconfigured environment with the necessary toolchain and creates a github release.

To house all of the components together, I created a rought 3D design on Tinkercad with space to fix the Raspberry Pi and the sensors in a Box. The design looks... unfortunate but then, I am just starting to learn 3D modeling. Printed the model using my college's 3D printer after months on grueling paperwork.

Now that this is complete, the only thing left is to deploy this in my college. Which is easier said than done because of college politics and unnecessary bureaucracy. Suddenly a lot of people will be upset with me as soon as this is deployed. I want to avoid that. As good as I am with computers, I am equally as bad at dealing with people. Testing this in a production environment with real users is still a thing left to do. Also the face recognition does not have liveliness detection yet which is a huge flaw that I am willingly ignoring for now. I'll add that soon.

This project taught me what building a real-world application looks like. The challenges of building something that integrates a lot of systems and works across different platforms are immense. This was wayy more rewarding and fun than a simple ToDo app clone. In this age of cheap, mass produced software, the winning edge is building quality software.

I have also made a youtube video demonstrating this project. Thanks for reading!

AttendPi

Wed, 16 Jul 2025 00:00:00 GMT

::github{repo="shub39/attendpi"}

An attempt at making a biometric attendance system for the raspberry pi 4B written in Rust.

This is Kind of a port of my previous project in python

Why?

Python is too slow.
bad IDEs and tooling for the Raspberry pi (pip, geany).
No types in Python :(
I'm a masochist and I like to overdo everything.
Wanted to learn Rust through a challenging project.

What I used?

Hardware

R305 fingerprint sensor by Adafruit. Connected through UART

4x4 GPIO keypad

ssd1305 oled display

Raspberry pi 4B (8gb)

Software

Rustrover by JetBrains

Standard ssh stuff

What I did?

At first I thought it would be as simple as rewriting the core modules of the system in Rust. And I was wrong. Doing some initial research I found out there are no crates to handle communication with the fingerprint sensor. I should have stopped right there.

I spent the next 8 hours deep into the serial communications rabbi thole and somehow got a module working at the end of it to store and search fingerprint templates using the sensor. I immediately realised that Rust is way better than python in terms of tooling and language features. I was able to write a proper struct to represent the sensor in runtime with proper typed errors, and it felt great. And then I called it a day

I compiled the debug binaries in my main machine and executed on the raspberry pi via ssh. It was going smooth with a bash script.

The next day I decided to tackle the display stuff. Couldn't find a crate to handle my specific ssd1305 display but got the next best thing. A crate to handle ssd1306 displays. Quickly wrote a script to handle that but the display was rendering funky. It would always skip every other row of pixels in the default 128x32 configuration.

I spent way too long trying to figure out what's going wrong. In other display configurations, it would fill all pixels but with repeating text and inconsistencies. Eventually I gave up on it and settled with a hacky solution suggested by AI, skipping every other row of pixels while rendering in 128x64. still it would incorrectly render some pixels at the edge of the display. Ended day 2

Day 3 and I started working on getting the Keypad working. It was fairly simple using the rppal crate. Got a working struct for it too and it was working as expected. Till now I was very impressed by the results. The sensors were really fast and responsive and I faced way less errors during sensor communication unlike in python.

Then I tried to get the camera working and realised its a mess. There are many crates to handle standard raspberry pi cameras but they require 32-bit OS and I was way in too deep to try and change everything I have done till now. On the other hand there were no good face_detection and machine learning crates that would compile without errors even on the raspberry. AI was suggesting to use python via FFI but that defeated the whole purpose of starting this project.

Ultimately decided to drop this and just put up with python for now. Maybe I'll revive this attempt later with a different purpose and skill. For now this is just a reminder and reference, and a lesson to not go all in on bleeding edge stuff as its almost always counter productive