The night before the actual Hackathon, It was intense knowing it will be a tough competation and i was hoping not to embarrce my self in front of all the judges and crowd.

I went in with curiosity. I walked out as part of the 2nd Runner-Up team, with a project I was genuinely proud of.

The Challenge

The goal was simple: build something meaningful under pressure.

The reality was tougher. Shifting requirements, time running out, bugs appearing out of nowhere, and constant context-switching made the process chaotic in the best way possible.

But that’s exactly what a hackathon is supposed to feel like.

Our Project: humanSign

Our team built something we had never attempted before — an AI-powered Human Detection System based entirely on keystroke patterns.

How It Works

• We capture raw typing events:
• Key press (down) timestamps
• Key release (up) timestamps
• Delays between consecutive keys
• Hold times per key
• These values form a behavioral signature for each user.
• We convert those signatures into feature vectors and feed them into an ML model.
• The model predicts whether the input is:
  • Human
  • Bot/Script

This method is privacy-friendly because it doesn’t track what is typed — only how it’s typed.

Why It Matters

Bot detection traditionally relies on IP, captchas, or rate limiting. Our system focuses on behavior, making it extremely difficult for bots to mimic.

It’s lightweight, accurate, and can be integrated into login pages, forms, or security checkpoints. Building Under Pressure Creating this system within a limited time required: Real-time event capturing Feature engineering Training and tuning a model Designing a simple interface Testing under unpredictable conditions Preparing a clear pitch for the judges Each step was a mini-challenge. Each challenge pushed us to think faster and work smarter.

The Moment That Counted

When we presented the demo — typing a short sentence and watching the system instantly classify the input as human — the judges leaned forward.

That was the moment we knew the project had impact. Being announced as the 2nd Runner-Up was the final confirmation.

What I Learned

The hackathon reinforced a few important lessons: Good ideas come from simple observations. Machine learning shines when paired with human behavior patterns. Teamwork and clarity matter as much as coding skills. A working prototype beats a perfect plan. Most importantly, it showed me that innovation doesn’t need huge systems. Sometimes, it starts with something as small as a keystroke.

Source: https://github.com/sumit-poudel

When I first booted into HyDE + Hyprland, I had no clue how deep the rabbit hole went.
Everything looked barebones. No panels, no menus, no polish. Just a tiling compositor staring back at me.

I wanted to daily-drive it, but at the start it was a mess. Configs breaking, keybinds missing, windows tiling in ways I didn’t understand. It felt like living in a half-finished house.

Hunting for Dotfiles

That’s when I did what every Hyprland beginner does—stole dotfiles.

• Picked up some configs from my senior Biijesh.
• Borrowed pieces from Caelestia dot.
• Dug through Gaurav’s simple-hyprland setup.
• Glued it all together with random snippets from GitHub and Reddit.

Every import broke something new. Wrong paths, weird dependencies, mismatched versions. But that’s how I learned. Each config line was a lesson in how Hyprland ticks.

Building My Own Setup

Slowly, I stopped just copying. I started shaping.

• Waybar for the status bar.
• Wlogout for session management.
• swww and mpvpaper for wallpapers.
• Swaync for notifications.
• Tofi as a fast, minimal launcher.

Piece by piece, I bent Hyprland to my workflow. My desktop stopped feeling like a borrowed skin and started feeling like mine.

Why It Mattered

Hyprland taught me something Arch once did:

• Copying gets you started. Creating keeps you going.
• Every crash log is a roadmap.

What began as scattered dotfiles turned into my own system. Not perfect, not final, but mine.

In that moment, I wasn’t just using Hyprland.
I was building my own environment on it.

Source: https://github.com/sumit-poudel/dotfiles

Maybe my last as well.

Diving Into Arch With No Clue

I jumped into Arch Linux with zero idea what I was doing. No roadmap, no hand-holding—just me and the terminal. I told myself I’d daily drive it. Sink or swim. And at first, it felt like drowning.

Broken configs. Missing packages. Endless updates. Every day was a new puzzle. But that’s what made Arch different: it forces you to learn.

Discovering the AUR

Then I stumbled upon the AUR (Arch User Repository). It felt like unlocking a hidden level. Suddenly, Arch wasn’t just about installing what others had made. It was about building, shaping, and contributing.

And that’s when the idea hit me—what if I could put my own app there?

Wrestling With PKGBUILD

I had an Electron app image. No clue how to turn it into a package. So I opened the Electron docs. Found some random guy’s PKGBUILD on GitHub. Copied. Tweaked. Failed.

Over and over.

Missing dependencies. Wrong paths. Broken installs. Every error felt like the system was laughing at me. But with each failure, I learned. Slowly, painfully, the puzzle started to make sense.

The Moment It Worked

After countless retries, I ran the build again. This time, no red errors. Installed clean. Launched smooth.

My first AUR package.

It was more than just code running—it was proof. Proof that I could bend Arch to my will. Proof that struggle builds weight.

Why It Mattered

Arch taught me this:

• Light wins come fast but vanish fast.
• Heavy wins shape you.

And that first AUR package? It was heavy. It carried all my failed attempts, all the frustration, all the learning.

In that moment, I wasn’t just using Arch.
I became someone who could create for it.

Source: https://github.com/sumit-poudel/oWtE