DEV Community: Nishant Mishra

Flying the Felis 747-200 in X-Plane 12: Learning to Operate and Master the Queen of the Skies

Nishant Mishra — Fri, 25 Sep 2026 12:05:36 +0000

There is something slightly intimidating about sitting in the cockpit of a Boeing 747-200.

Four engines. A flight engineer's panel. Multiple fuel tanks. Hydraulics. Pneumatics. Electrical systems. Pressurization. Engine Pressure Ratio. Navigation systems. And, if you decide to go all the way back to the aircraft's original era, a CIVA INS navigation system that makes modern navigation look almost suspiciously convenient.

This is exactly why I wanted to learn the Felis 747-200 Classic in X-Plane 12.

My goal isn't simply to get the aircraft airborne, engage the autopilot and watch the scenery go by.

I want to understand what the aircraft is doing, why it is doing it, and how all of those individual systems come together to operate a classic long-haul aircraft.

I'm currently using the FMC as my primary navigation method. Eventually, I want to learn the CIVA INS properly, but trying to learn the entire aircraft and a completely different navigation philosophy at the same time would be an excellent way to turn a training flight into a troubleshooting session.

So this article is my journey from being intimidated by the aircraft to finally feeling comfortable enough to operate it.

And eventually, I put all of that learning to the test on DLH100, Frankfurt (EDDF) to Madrid (LEMD).

Why the 747-200?

The 747-200 belongs to a very different generation of aviation.

Modern airliners are designed around highly integrated computers, automation and simplified crew workflows. The classic 747 was also technologically advanced for its time, but its operating philosophy was different.

The aircraft expected the crew to understand its systems.

The real 747-200 flight deck had three crew members:

Captain
First Officer
Flight Engineer

The flight engineer wasn't simply sitting behind the pilots watching gauges.

The position existed because managing a large aircraft's electrical, hydraulic, pneumatic, fuel and other systems required significant attention.

The Felis simulation captures much of that philosophy.

That makes the 747-200 interesting to fly because it isn't just a large aircraft.

It is a large system-management exercise.

Getting Familiar With the Felis 747-200

The Felis 747-200 Classic for X-Plane 12 is built around detailed aircraft systems rather than simply providing a visually accurate 747.

The aircraft includes detailed simulation of systems such as:

Electrical power
Fuel
Hydraulics
Pneumatics
Pressurization
Engines
Autopilot
Autothrottle
EPR-based thrust management
Navigation
Flight engineer functions
EFB-based aircraft management

This means learning the aircraft isn't really about memorizing where every switch is.

It is about understanding how the systems interact.

The easiest way for me to approach that was to break the aircraft into smaller pieces.

Understanding the Aircraft Without Getting Overwhelmed

The biggest mistake I could make would be thinking I have to understand everything immediately.

I don't.

The better approach is to understand what each major system does first.

Once the purpose of a system makes sense, the switches and procedures become much easier to understand.

Electrical

Think of it as:

Source → Bus → Equipment

The aircraft receives electrical power from sources such as generators or external power.

That power is distributed through electrical buses.

Those buses supply the aircraft's systems and equipment.

I don't need to memorize every electrical circuit immediately.

The first objective is simply understanding where the electricity comes from and where it goes.

Fuel

The 747 has multiple fuel tanks and a fuel system designed to supply four engines while maintaining appropriate fuel distribution.

The basic mental model is:

Fuel tanks → Pumps → Fuel distribution → Engines

The complexity comes from how the tanks and pumps are managed.

Fuel management involves more than simply asking whether enough fuel remains.

It also involves:

Tank sequencing
Fuel balance
Engine feed
Fuel transfer
Pump operation
Aircraft weight
Centre of gravity
Remaining fuel

The aircraft has a lot of fuel.

But "a lot" is not an aircraft procedure.

Automatic Fuel Management for Long-Haul Flights

For long-haul operations, I also use an automatic fuel-management plugin to reduce repetitive workload.

On shorter flights, manually managing the fuel system is useful because it teaches me what the aircraft is doing.

On longer flights, however, constantly performing repetitive fuel-management tasks can become another workload item competing for attention with everything else happening in the cockpit.

The philosophy is simple:

Let automation handle repetitive tasks while I remain responsible for understanding and monitoring the system.

My long-haul workflow therefore looks something like this:

Felis 747-200
Aircraft and systems

XFirstOfficer
Crew workload and procedural assistance

Automatic fuel-management plugin
Repetitive fuel-management tasks

SimGround Map
Ground and airport awareness

FMC
Current navigation solution

Pilot
Flight management and decision-making

The important distinction is that automation should reduce workload, not replace understanding.

I still want to understand what the fuel system is doing.

The plugin simply means I don't have to spend an entire long cruise repeatedly performing the same fuel-management actions.

Hydraulics

The hydraulic system is easier to understand if you think of it as a power transmission system.

The basic idea is:

Pump → Pressurized fluid → Actuator → Movement

Hydraulic pressure provides the force required to move aircraft components.

Depending on the system, hydraulics support functions such as:

Flight controls
Landing gear
Brakes
Other high-force aircraft mechanisms

The important thing initially isn't memorizing every hydraulic line.

It is understanding that the aircraft needs a powerful way to move heavy mechanical components.

Hydraulic pressure provides that power.

Pneumatics

Pneumatics deal with compressed air.

A simplified model is:

Engine → Compressed/bleed air → Pneumatic system → Aircraft services

Bleed air can support functions including:

Air conditioning
Pressurization
Engine-related systems
Other pneumatic services

Again, understanding the relationship between the components is more useful initially than memorizing every valve.

Pressurization

At cruise altitude, the atmosphere is not particularly interested in human survival.

The aircraft therefore maintains a controlled cabin environment.

The basic idea is:

Conditioned air enters the cabin → air leaves through controlled outflow → cabin pressure is maintained

The aircraft isn't simply trapping air inside.

It continuously manages airflow and pressure.

Once that concept makes sense, the pressurization system becomes much easier to understand.

The Engines and EPR

The 747-200's four engines are another major part of the learning experience.

Unlike many modern aircraft where thrust settings are presented primarily through N1 percentages, the classic 747 uses Engine Pressure Ratio, or EPR, as an important thrust reference.

Conceptually:

EPR = engine exhaust pressure compared with engine inlet pressure

I don't need to manually calculate it during every phase of flight.

What matters initially is understanding that EPR provides a reference for engine thrust.

That becomes particularly important during takeoff and climb because thrust limits depend on factors such as:

Temperature
Pressure altitude
Aircraft weight
Engine configuration
Takeoff conditions

Performance calculations therefore matter.

A 747 isn't something you casually point down the runway and hope physics has decided to cooperate.

Starting Four Engines

Starting four engines is one of those moments where the aircraft immediately reminds you that you're operating something from another era.

The process involves monitoring engine parameters rather than simply clicking a single "start engines" button.

I'm watching:

Engine rotation
Fuel flow
Temperature
Oil pressure
Engine stabilization

An engine start isn't just an animation.

It is a sequence of physical processes that I monitor.

Once all four engines are stable, the aircraft becomes a completely different machine.

XFirstOfficer: Sharing the Workload

One of the most useful additions to my workflow is XFirstOfficer.

My philosophy for using it is simple:

Don't automate the thinking. Delegate the workload.

The real 747 had another crew member sitting beside the captain.

In the simulator, XFirstOfficer helps recreate some of that workload distribution by assisting with routine cockpit tasks, checklists, monitoring, callouts and procedural actions depending on the configuration being used.

That changes how I approach the aircraft.

Instead of trying to personally operate every switch while simultaneously navigating, monitoring engines, communicating and flying the aircraft, I can distribute some of the repetitive workload.

That is especially useful in a classic aircraft because there are plenty of things happening simultaneously.

But the virtual First Officer isn't replacing the pilot.

I still need to understand:

What is happening?
Why is it happening?
What should happen next?
Is the aircraft behaving normally?

Automation is useful when it gives the pilot more mental space.

SimGround Map: Knowing Where You Are on the Ground

The cockpit isn't the only place where situational awareness matters.

Large airports can become surprisingly confusing when you're sitting several stories above the ground in a 747.

That is where SimGround Map becomes useful.

It provides a real-time view of the aircraft's position and the surrounding airport environment, making it easier to understand:

Taxiways
Runways
Parking positions
Airport layout
Aircraft position

For a large aircraft, ground navigation is its own little flight.

You're dealing with:

Long wings
Large turning radius
Taxiway restrictions
Runway crossings
Parking positions
Other aircraft and vehicles

Having a clear map reduces the cognitive load.

It doesn't fly the aircraft.

It simply makes it easier to understand where I am.

FMC First, CIVA Later

This is probably the biggest deliberate decision in my current learning process.

The 747-200 can be flown using the CIVA INS, which is one of the most interesting aspects of operating a classic long-haul aircraft.

But I'm not starting there.

I'm using the FMC first.

Why?

Because there are already enough things to learn.

If I simultaneously try to learn:

747 systems
Flight engineer procedures
Engine management
Performance
EPR
Fuel management
Pressurization
Electrical systems
Hydraulics
Pneumatics
CIVA INS

I'm not really learning.

I'm increasing the number of things capable of confusing me.

So my progression is:

FMC → Aircraft confidence → CIVA INS

Once I'm comfortable operating the aircraft, I'll move toward the INS.

Understanding CIVA INS

The CIVA concept is actually easier to explain than its cockpit implementation suggests.

At its most basic level:

Know where you started + measure how you moved = estimate where you are now

The INS uses inertial measurements to calculate aircraft movement and continuously estimate position.

That makes it fundamentally different from simply following a modern satellite-based navigation solution.

The appeal is that you're operating a navigation system from the era in which long-haul crews had to manage navigation very differently.

But it also means more responsibility.

That is exactly why I want to learn it after becoming comfortable with the aircraft itself.

The Takeoff

The takeoff phase brings everything together.

Before departure, I want to know:

Aircraft weight
Takeoff performance
Engine configuration
Thrust setting
Flap configuration
Trim
Fuel status
Pressurization status
Flight controls
Navigation setup

The 747 is big enough that every action feels deliberate.

Once the engines are producing takeoff thrust and the aircraft begins accelerating, the scale of the machine becomes obvious.

Then comes rotation.

And suddenly the enormous four-engine aircraft is airborne.

Climb

The climb is where the workload begins to settle.

The aircraft transitions from the intense environment of takeoff into a more predictable phase of flight.

This is where automation becomes useful.

The autopilot can maintain the aircraft's flight path while I focus on monitoring:

Engines
Fuel
Pressurization
Hydraulics
Electrical systems
Navigation
Aircraft performance

This is also where the aircraft begins to feel less like a collection of switches and more like a functioning machine.

Cruise

Cruise is where the 747 really starts to feel like a long-haul aircraft.

The aircraft settles into its rhythm.

The engines are stable.

The autopilot is flying.

The aircraft is following its route.

Fuel is being consumed.

The crew monitors the aircraft and manages what needs managing.

This is also where my supporting tools become most useful.

My cruise setup

Felis 747-200

The aircraft itself and its detailed systems.

XFirstOfficer

Helps distribute routine cockpit workload.

Automatic fuel-management plugin

Handles repetitive fuel-management tasks during long flights while I continue monitoring the fuel system.

SimGround Map

Primarily useful before departure and after arrival, but still part of the overall operational toolkit.

FMC

My current navigation solution.

CIVA

My future navigation challenge.

The result is a workflow that feels much more like managing a flight than simply flying an aircraft.

Long-Haul Fuel Management

A long-haul 747 flight can involve hours of cruise.

That makes fuel one of the most important things to monitor.

I'm interested in three basic questions throughout the flight:

1. How much fuel did I start with?

This establishes the baseline.

2. How much fuel am I burning?

This tells me whether the aircraft is behaving approximately as expected.

3. How much fuel will I have when I arrive?

This is ultimately the number that matters.

Fuel management is therefore not simply:

"Look at the fuel gauges."

It is continuous awareness of fuel consumption, distribution, aircraft weight and expected arrival fuel.

Automation can help with repetitive tasks, but the pilot still needs to understand the numbers.

A plugin can manage fuel.

It cannot take responsibility for the flight.

The Flight That Changed Everything: DLH100

Eventually, all the learning has to be put into practice.

For me, that flight was DLH100 from Frankfurt (EDDF) to Madrid (LEMD).

It wasn't chosen because it was some spectacularly difficult route.

In fact, that was part of the point.

I wanted a flight long enough to exercise the aircraft's systems, but manageable enough that I could concentrate on operating the 747 rather than spending the entire flight fighting it.

The setup was:

Flight: DLH100
Route: EDDF → LEMD
Aircraft: Felis 747-200 Classic
Navigation: FMC
Crew assistance: XFirstOfficer
Ground awareness: SimGround Map
Fuel management: Automatic fuel-management plugin

This was the flight where I finally felt that everything had clicked.

Frankfurt: Setting Up the Queen

Frankfurt immediately reminded me why the 747 is such an interesting aircraft.

There is a lot to do before the aircraft even moves.

I worked through the cockpit preparation systematically.

Electrical power.

Aircraft configuration.

Fuel.

Hydraulics.

Pneumatics.

Pressurization.

Navigation.

Performance.

Engines.

Instead of looking at the cockpit as one enormous wall of switches, I could mentally divide it into systems.

That made an enormous difference.

Earlier in my learning process, I would look at a panel and think:

"What does all of this do?"

Now I could look at it and think:

"This is the electrical system. This is the fuel system. This is the pneumatic system."

That shift sounds small.

It isn't.

It is the difference between looking at a complex aircraft and understanding a complex aircraft.

Programming the Flight

For DLH100, I stayed with the FMC.

I deliberately decided not to introduce CIVA yet.

That wasn't because I had abandoned the idea of learning INS navigation.

Quite the opposite.

I wanted to learn CIVA properly, and that meant first becoming comfortable enough with the aircraft that I could devote my attention to navigation rather than fighting the airplane itself.

The route was entered.

The departure was prepared.

The arrival into Madrid was planned.

The aircraft was ready.

Four Engines Come Alive

Engine start was one of the moments that made me realize how much progress I had made.

Previously, starting the 747 could feel like a checklist exercise.

Now I understood what I was actually watching.

Engine rotation.

Fuel introduction.

Temperature rise.

Oil pressure.

Stabilization.

One engine at a time, the four powerplants came alive.

The aircraft went from a collection of systems sitting quietly at the gate to a functioning machine.

And somewhere in the cockpit, my virtual First Officer was helping keep the workload under control.

I wasn't trying to touch every control.

I was managing the operation.

Taxiing Out of Frankfurt

With the engines stabilized, I began taxiing.

This is where SimGround Map proved useful again.

Frankfurt is not exactly a tiny airfield where you can simply point the aircraft toward the runway and hope.

The 747's size also makes ground navigation something that deserves attention.

Taxiway.

Hold short.

Runway crossing.

Turn.

Position.

Check.

Move.

The aircraft's wings extend far beyond what your brain initially expects.

Every turn is a reminder that you're driving something with the approximate footprint of a small apartment building.

Eventually, we reached the departure runway.

The aircraft was configured.

The takeoff data was checked.

The engines were ready.

The 747 was pointed toward Madrid.

Takeoff

Takeoff was where everything I had learned started coming together.

The engines spooled up.

Thrust was established.

The aircraft accelerated.

The numbers came alive.

And then:

Rotate.

The nose came up.

The 747 lifted away from Frankfurt.

Four engines pushed the aircraft into the climb.

The landing gear came up.

The aircraft transitioned into its climb profile.

For the first time, I wasn't thinking:

"Am I doing this correctly?"

I was thinking:

"The aircraft is doing exactly what I expect."

That was the moment.

The beast was no longer something I was merely trying to survive.

I was actually flying it.

Climbing Away

The climb was surprisingly calm.

XFirstOfficer helped with the routine workload.

The autopilot handled the flight path.

I monitored the aircraft.

Engine indications.

Fuel.

Pressurization.

Hydraulics.

Electrical systems.

Navigation.

Everything had a purpose now.

Instead of randomly checking gauges because they existed, I was checking them because I understood what they represented.

That is a major difference when learning a complex aircraft.

Cruise: The Moment It Clicked

Eventually, the aircraft settled into cruise.

This was where I noticed the biggest change.

The cockpit suddenly felt familiar.

The systems weren't fighting for my attention.

The aircraft was stable.

The FMC was managing the route.

The autopilot was maintaining the flight path.

XFirstOfficer was helping with routine workload.

The automatic fuel-management system was handling repetitive fuel-management tasks.

And I was monitoring the operation.

I looked around the cockpit and realized something:

I knew what I was looking at.

The panels that had once seemed intimidating now had context.

The fuel gauges told a story.

The engine instruments told a story.

The electrical panel told a story.

The hydraulic indications told a story.

The pressurization system told a story.

I wasn't memorizing switches anymore.

I was interpreting the aircraft.

That, to me, was what finally mastering the beast meant.

Not knowing every single switch by heart.

Knowing enough about the machine to understand what it was telling me.

The Flight to Madrid

The cruise itself was relatively uneventful.

And that was exactly what I wanted.

A well-managed aircraft should eventually become boring.

Boring is good.

Boring means the systems are stable.

Boring means the fuel burn is behaving as expected.

Boring means the engines are happy.

Boring means nobody has accidentally created an aviation incident because they got distracted by the scenery.

The flight continued toward Spain.

I continued monitoring the aircraft.

Fuel management remained in the background.

The route progressed.

The workload remained manageable.

And I had time to appreciate the fact that I was finally comfortable in the cockpit.

Descending Toward Madrid

Eventually, Madrid began to approach.

The cruise phase ended.

The arrival was prepared.

The aircraft began its descent.

This was another useful test.

The aircraft had to transition from the quiet environment of cruise back into a much more active phase of flight.

Speed.

Altitude.

Configuration.

Navigation.

Approach planning.

Fuel.

Everything mattered again.

But this time, the workload didn't feel overwhelming.

I knew what was coming.

Approach Into LEMD

Madrid gradually came into view.

The 747 descended toward the airport.

The aircraft configuration changed progressively.

Flaps.

Speed.

Descent path.

Landing preparation.

The workload increased, but the cockpit still felt under control.

That was another sign of progress.

Earlier, I would have considered a busy approach something to fear.

Now I considered it something to manage.

There is a subtle difference.

Fear says:

"There are too many things happening."

Experience says:

"There are several things happening. Handle them one at a time."

The Landing: -879 FPM and 1.49 G

And then came the part that I probably shouldn't put in the aviation equivalent of a trophy case.

The landing was not exactly textbook.

The recorded touchdown was approximately:

Vertical speed: -879 feet per minute
Peak/recorded load: 1.49 G

In other words, the Queen of the Skies did not exactly float onto the runway like a feather.

She arrived.

With conviction.

A 1.49 G touchdown is a substantial impact, and a descent rate of -879 fpm at touchdown is considerably harder than the kind of smooth landing most pilots would aim for.

But strangely enough, this landing was useful.

It exposed the final part of the learning process that I still needed to work on.

I had learned the systems.

I had learned the workflow.

I had learned the navigation.

I had learned the workload management.

But landing a large classic jet smoothly is another skill entirely.

The aircraft can be completely understood and still demand better handling.

And that is an important lesson in simulation:

Mastering the systems doesn't automatically mean mastering every phase of flight.

So yes, DLH100 ended with a fairly enthusiastic arrival.

The runway survived.

The aircraft survived.

My pride survived, although it filed a formal complaint.

What DLH100 Taught Me

The most important lesson from the flight wasn't navigation.

It wasn't fuel management.

It wasn't even the landing.

It was confidence.

Not blind confidence.

System-based confidence.

I knew why I was doing things.

I understood what the aircraft was telling me.

I knew where the workload was coming from.

I knew when automation could help.

And I knew that I was still responsible for the flight.

That is what changed.

The -879 fpm and 1.49 G touchdown also gave me something important: a new training target.

The aircraft systems had started to feel familiar.

Now I could concentrate more seriously on refining my flying.

From Learning the Beast to Flying the Beast

When I first started learning the Felis 747-200, the aircraft felt enormous.

Not just physically.

Mentally.

There were too many systems.

Too many switches.

Too many procedures.

Too many things to remember.

But the solution wasn't to memorize everything.

The solution was to understand the aircraft one system at a time.

Eventually:

Electrical → understood

Fuel → understood

Hydraulics → understood

Pneumatics → understood

Pressurization → understood

Engines → understood

EPR → understood

FMC → comfortable

XFirstOfficer → integrated

Fuel management → integrated

Ground operations → familiar

And then came DLH100.

The flight where all those individual pieces finally became one operation.

The landing wasn't perfect.

Far from it.

But the overall flight demonstrated something much more important.

I could operate the aircraft.

The Next Challenge: CIVA

Mastering the aircraft doesn't mean the learning is finished.

It means I can finally move on to the next layer.

For me, that is CIVA INS.

Now that I have enough confidence with the aircraft itself, I can start learning the navigation system without simultaneously trying to understand the entire 747.

That is an important distinction.

I'm not replacing the FMC because it is easier.

I'm using the FMC as the bridge toward understanding classic navigation.

Eventually, I want to fly the 747 using the kind of navigation workflow appropriate to the aircraft's era.

That will be another challenge.

And probably another article.

The Learning Roadmap

My approach to the Felis 747-200 now looks something like this.

Stage 1: Learn the aircraft

Understand:

Electrical
Fuel
Hydraulics
Pneumatics
Pressurization
Engines
Flight controls

Stage 2: Learn normal operations

Practice:

Engine starts
Taxi
Takeoff
Climb
Cruise
Descent
Approach
Landing

Stage 3: Use automation intelligently

Integrate:

Autopilot
Autothrottle
XFirstOfficer
Automatic fuel management

The goal isn't maximum automation.

The goal is appropriate workload distribution.

Stage 4: Improve navigation

Continue with the FMC until it becomes comfortable.

Then begin learning:

CIVA INS

Stage 5: Improve aircraft handling

Now that the systems are becoming familiar, concentrate on:

Smoother approaches
Better flare timing
Landing attitude
Touchdown control
Energy management
More consistent landings

Because apparently knowing how the aircraft works does not magically make the runway softer.

Stage 6: Fly longer and more realistically

Eventually, combine everything into realistic long-haul operations.

That means managing:

Flight planning
Fuel
Aircraft systems
Navigation
Crew workload
Weather
Diversions
Arrival planning

Learn Manually First. Automate Later.

This is probably the principle I want to keep throughout the entire learning process.

Automation is useful.

Plugins are useful.

The FMC is useful.

XFirstOfficer is useful.

Automatic fuel management is useful.

But none of those things should become substitutes for understanding the aircraft.

The objective isn't to make the 747 behave like a modern automated airliner.

The objective is to understand how the 747 was designed to operate and then use simulation tools to make that learning manageable.

The aircraft remains the aircraft.

The pilot remains responsible for the flight.

The software simply helps distribute the workload.

Final Thoughts

Flying the Felis 747-200 in X-Plane 12 has turned out to be less about learning how to fly a big airplane and more about learning how to manage a complex machine.

The aircraft forces you to think about systems.

The flight engineer concept forces you to think about workload.

The fuel system forces you to think ahead.

The CIVA INS promises to make navigation considerably more interesting.

XFirstOfficer helps distribute routine crew workload.

SimGround Map improves situational awareness on the ground.

An automatic fuel-management plugin can reduce repetitive fuel-management work during long-haul flights.

But the most important part is still the pilot.

DLH100, EDDF to LEMD, became the point where all of those lessons came together.

It wasn't perfect.

The -879 fpm touchdown and 1.49 G landing made that very clear.

But perfection wasn't the point.

The important part was that I no longer felt like I was fighting the aircraft.

I understood what it was doing.

I understood why it was doing it.

I could manage the workload.

I could monitor the systems.

I could navigate the aircraft.

And when something didn't go perfectly, I could identify what needed more practice.

That is what I now consider mastering the beast.

Not becoming perfect.

Becoming comfortable enough with the machine that I can concentrate on improving the details.

The Felis 747-200 is still a demanding aircraft.

But it no longer feels impossible.

And now that I've managed to tame one Queen of the Skies, there is only one obvious next challenge:

learn to navigate her properly with CIVA.

Because apparently learning one 747 wasn't enough. ✈️

Why I Haven’t Posted on DEV.to Since July

Nishant Mishra — Wed, 26 Aug 2026 14:16:46 +0000

There has been a suspicious amount of silence from this account.

My last DEV.to post was in July 2026.

And then...

Nothing.

No Linux deep dives.
No project updates.
No technical write-ups.
No carefully constructed "10 Things I Learned From..." article.

The internet survived. Somehow.

But if you're wondering why I went quiet, the answer is much simpler than "I was secretly building the next revolutionary startup."

I was dealing with life.

I didn't stop being a developer

Not publishing doesn't mean I stopped learning.

I was still working with Linux. Still thinking about software. Still working on personal projects. Still experimenting, troubleshooting, breaking things and figuring out why they broke.

That last part remains a fairly reliable developer tradition.

But my priorities changed.

Career decisions, job hunting, personal responsibilities, uncertainty and everything else happening outside a terminal window started taking up most of my attention.

There are periods when you have plenty to write about.

Then there are periods when you're mostly trying to figure out what comes next.

I was in the second category.

July was the beginning of a different phase

After leaving my previous role, the focus shifted toward figuring out my next step.

The job hunt became a full-time activity of its own.

Applications.

Interviews.

Resume revisions.

Technical discussions.

Researching companies.

Thinking about salaries.

Applying again.

And occasionally staring at a job description wondering whether the recruiter actually wants a human being or three certifications, seven years of experience and the ability to function without sleep.

During that period, writing simply wasn't my priority.

And that's okay.

My projects didn't disappear

One thing this break reminded me of is that a project doesn't become meaningless just because you haven't pushed a commit recently.

I've continued thinking about my personal projects, including Archangel Security Suite.

Some things moved forward.

Some things moved slowly.

Some things are still sitting there waiting for me to return to them.

That's normal.

There is an interesting pressure in developer communities to constantly ship.

New project.

New release.

New framework.

New blog post.

New GitHub contribution.

Repeat.

But software development isn't always a straight line.

Sometimes you're building.

Sometimes you're researching.

Sometimes you're learning.

And sometimes you're simply trying to get your life back into a stable state.

I didn't want to post just for the sake of posting

This was probably the biggest reason for the silence.

I could have written another generic tutorial.

I could have made another listicle.

I could have written something purely because I hadn't published anything recently.

But I didn't want to.

If I'm going to write here, I'd rather have something meaningful to share.

Technology is a huge part of my life, but so is the journey around it.

The career changes.

The projects.

The experiments.

The failures.

The lessons.

The strange decisions that somehow make sense three months later.

Those stories are worth documenting too.

Sometimes you need to step away from the keyboard

There is a strange expectation in technology that we're supposed to constantly produce.

Code.

Articles.

Projects.

Certifications.

GitHub contributions.

Conference talks.

Posts.

At some point, it starts to feel like developers are expected to operate as content-generation systems with keyboards attached.

But life doesn't work that way.

Sometimes you need to step away from the keyboard.

Sometimes your attention needs to go somewhere else.

And taking a break doesn't mean you've stopped being a developer.

It means you're a person before you're a GitHub graph.

So, what's next?

I'm writing again.

Not because I suddenly have everything figured out.

I definitely don't.

I'm writing because I'm still curious.

Still learning.

Still building.

Still interested in Linux, security, software, infrastructure, open source and all the wonderfully strange corners of technology that keep pulling me back.

The next posts may be technical.

They may be about projects.

They may be about Linux.

They may be about lessons from my career transition.

And some may simply be about things I've learned along the way.

That's the kind of writing I want to do.

The silence wasn't the end

Looking back, the gap since July doesn't really feel empty.

A lot happened during it.

Some things were difficult.

Some were frustrating.

Some were exciting.

Some are still unresolved.

But the important part is this:

I never stopped moving.

The blog went quiet.

The learning didn't.

The projects didn't.

The curiosity didn't.

And now the writing is starting again.

So this isn't really a comeback.

It's simply resume.

The journey continued while the blog was quiet.

Now I'm documenting it again.

Back to writing. Back to building. Back to breaking things and figuring out why they broke.

See you in the next post. 🚀

Building PocketPilot and Archangel Security Suite: My Journey Into Practical Developer Tools

Nishant Mishra — Sun, 12 Jul 2026 07:53:38 +0000

Every great project begins with a simple question:

"Can I build something that solves a real problem?"

For me, that question led to the creation of two open-source projects: PocketPilot and Archangel Security Suite.

At first, they appear to solve completely different problems.

PocketPilot focuses on personal finance management.

Archangel Security Suite focuses on cybersecurity and defensive security tooling.

But both projects share the same philosophy:

Technology should empower people by giving them more control, visibility, and confidence.

The Idea Behind PocketPilot

Managing personal finances is important, but many existing applications are overloaded with features, advertisements, cloud dependencies, and complicated interfaces.

Sometimes users do not need a massive financial ecosystem.

They need simple answers:

Where did my money go?
How much did I spend?
What is my remaining budget?
Am I improving financially?

PocketPilot was created with the idea of building a simple, lightweight, privacy-focused budgeting tool.

Instead of forcing users into another application ecosystem, PocketPilot brings financial tracking into the command line.

The terminal has always represented simplicity and efficiency for developers. It is fast, distraction-free, and gives users direct control.

Why a CLI Finance Tool?

A command-line application provides several advantages:

Privacy

Financial information is personal.

PocketPilot follows a local-first approach by keeping users in control of their own data.

Speed

A lightweight CLI application launches quickly and integrates naturally into developer workflows.

Simplicity

Users should not need to navigate through hundreds of screens just to understand their spending.

Technology Behind PocketPilot

PocketPilot is built using:

Go

Go provides:

Fast execution
Simple development
Cross-platform support
Easy deployment

A single compiled binary makes distribution simple.

Cobra CLI

The Cobra framework provides clean command structures:

pocketpilot add
pocketpilot list
pocketpilot report

SQLite

SQLite provides reliable local storage without requiring a separate database server.

The Idea Behind Archangel Security Suite

Cybersecurity is becoming increasingly important.

Applications are more connected.
Threats are evolving.
Security mistakes can have serious consequences.

However, security tools can often feel complicated for beginners.

Archangel Security Suite was created around a simple idea:

Security knowledge should be accessible to everyone.

The goal is to create developer-friendly security tools focused on:

Defensive security
Automation
Learning
Awareness

Building Security Tools For Developers

Security should not be something added at the end of development.

Modern developers need security awareness throughout the software lifecycle.

Archangel Security Suite aims to help developers understand:

Secure configurations
Security checks
Vulnerability awareness
System protection concepts

The goal is not replacing security professionals.

The goal is helping developers build safer systems.

Open Source and Contributions

Both projects are open-source, and contributions are welcome.

PocketPilot

GitLab Repository:

https://gitlab.com/nishantm596/pocketpilot-cli

Contributions are welcome for:

New features
CLI improvements
Database enhancements
Testing
Documentation

Archangel Security Suite

GitLab Repository:

https://gitlab.com/nishantm596/archangel-security-suite

Contributions are welcome for:

Security modules
Automation features
Documentation
Testing
Developer experience improvements

Open-source grows because developers collaborate, review, experiment, and share knowledge.

Final Thoughts

PocketPilot and Archangel Security Suite represent two sides of the same vision.

One helps people manage their digital finances.

The other helps people protect their digital environments.

Both are built around one principle:

Build useful technology that gives people more control.

Software development is not only about writing code.

It is about solving problems, learning continuously, and creating something meaningful.

These projects are my attempt to turn ideas into reality.

OpenDev: From Zero Clients to Linux Independence – How I'm Building a One-Man Linux Revolution

Nishant Mishra — Tue, 26 May 2026 06:39:37 +0000

Published: May 26, 2026
Author: Rico (Nishant Mishra)
Reading time: 8 minutes
Alpha Launch: July 4, 2026

🇺🇸 Independence Day is Coming

America will celebrate independence on July 4. I'll celebrate something else: the Alpha launch of OpenDev.

Zero clients. One laptop. One supporter. One mission.

This is the story of how I'm building a Linux revolution from my laptop. No funding. No team. Just 8 years of daily driving, 12 broken Arch installs, and one person who believed before anyone else.
The Origin Story

I've been daily driving Linux since 2016.

Not in a VM. Not dual boot. Daily. Driving.

I've broken Arch 12 times. I've fixed Arch 12 times. I've spilled chai on my laptop (it survived). I've cursed at NVIDIA drivers (they did not). I've spent hours in TTY2, staring at a blinking cursor, wondering where it all went wrong.

Somewhere along the way, I realized something:

If I can break my system and fix it, I can help others do the same.

OpenDev was born.

The Philosophy

"Jo system ghar pe nahi chala sakte, wo office mein kyun lagaayein?"

Translation: "If you can't run it at home, why run it at work?"

Linux isn't a server in a dark room. It's not a dual boot you never boot into. It's not a terminal you fear.

It's your daily driver. At home. At work. Everywhere.

The Problem I'm Solving

Problem Reality

Fragmentation Ubuntu, Fedora, Arch, EndeavourOS – each needs different help

Hidden costs Cloud IDEs, CI/CD minutes, proprietary agents = ₹lakhs/year

Fear People try Linux, hit one bug, and go back to Windows

No trust Big IT is expensive. Local shops install cracked Windows. No one daily drives Linux.

India has 1.5 crore+ IT students. Most run Windows because "Linux is hard."

I'm changing that. One setup at a time.

What OpenDev Offers

For Home Users

Linux setup (remote)

Setup + 1-hour training

"Daily Drive" course

Monthly support

For Enterprises (Coming after Alpha)

Linux admin per device

One-time migration

Fractional Linux CTO

Alpha launch offer (July 4): First 5 Alpha users get FREE setup + lifetime "Alpha Pioneer" role.
The Daily Drive Course

From zero to daily driving in one month.

Curriculum:
Week Theme What You'll Learn
1 The Leap Choose distro, make live USB, install Linux
2 The Terminal Essential commands, package management, finding help
3 The Daily Drive Updates, peripherals, gaming, productivity
4 The Advanced Backups, troubleshooting, rescue fixes

What's included:

Live sessions (2x per week)

Recorded videos (watch anytime)

Private Discord channel

Cheat sheets (PDF)

Certificate of completion

Lifetime alumni access

The Streak Challenge

Here's the fun part.

Every OpenDev user joins the Linux Streak Challenge.

Report daily with !streak day X on Discord

Don't break your system

If you break, tell the story in #break-stories

Best break story each month wins a prize

Prizes include:

"I Didn't Break Linux" socks

Custom MS Paint wallpaper

Terrible Photoshop trophy

Discount codes

Milestones:

7 days → Shoutout

14 days → Raffle entry

30 days → Discount

60 days → Free training session

100 days → Lifetime alumni status

"Survive. Adapt. Win." – Arma 3

The Arch Ninja Bootcamp

For those who dare to install Arch.

4-week curriculum:
Week Theme Goal
1 The Initiation Install Arch manually
2 The Grind Master pacman + systemd
3 The Ascension Switch from DE to WM
4 The Ninja Clean install in under 1 hour

The Arch Ninja Creed:

"RTFM. Break. Fix. Repeat."

The Arch Wiki is my bible. Pacman is my sword. Systemd is my shield. The AUR is my secret weapon.

I will read the manual before I ask. I will break my system and fix it myself. I will not fear the black screen. I will not fear the blinking cursor.

"Who dares installs Arch. Who survives wins."

The Break Stories (Fictional – For Now)

Every break is a lesson. Here are fictional examples of breaks that will happen to someone:

Priya – Kernel 7.1 + NVIDIA

"I updated to kernel 7.1. NVIDIA drivers broke. Black screen. No TTY. Just darkness."

Fixed with: Live USB → chroot → downgrade kernel

Lesson: Wait 24 hours before kernel updates. Especially with NVIDIA.

Karthik – The Reddit Script

"I ran a GRUB theming script from Reddit. It formatted my EFI partition. Bricked."
Fixed with: Live USB → rebuild EFI → reinstall GRUB
Lesson: Never run random scripts as root. Always keep a live USB.

Sneha – Deleted Python

"My disk was full. I deleted Python 3.13. DNF died. GNOME died. Everything died."

Fixed with: Live USB → chroot → RPM force install → restore

Lesson: NEVER DELETE SYSTEM PYTHON. Disk space is cheap. Your system is not.

First real break story from Alpha/Beta wins a bonus prize + handmade certificate.
The Mottos

OpenDev is built on mottos from the world's finest warriors:

SAS 🇬🇧 "Who dares installs"
Navy SEALs 🇺🇸 "The only easy day was yesterday"
PARA SF 🇮🇳 "Men apart, every user an emperor"
Spetsnaz 🇷🇺 "The strongest update wins"
Arma 3 🎮 "Survive. Adapt. Win"

OpenDev's official motto:

"Don't break. Drive daily."

Hindi motto:

"तोड़ो मत। रोज़ चलाओ।"

The First Supporter

Every founder needs someone who believes before anyone else.

Mine is called Storm.

Storm uses Windows on a rusty desktop. Has never used Arch. Has never broken a Linux install.

Storm supports me. Not Linux. Not OpenDev. Me.

That's not business. That's love.

Storm is the First Supporter. Forever. The name is in the Supporters Hall of Fame. There's a Discord role waiting. Storm has never joined. May never join.

That's okay. Storm believed first. That's enough.

"Storm believed before anyone else."

Office hours (Discord voice):

Saturday & Sunday: 7-9 PM IST

Tuesday & Thursday: 7-9 PM IST (backup)

When travelling: off days = office hours

DM only for emergencies (system dead + work deadline)

The 10 Commandments of OpenDev
markdown

I. Thou shalt message Storm before Discord. Every day. (Rico's rule)
II. Thou shalt not fake a testimonial. Honesty > hype.
III. Thou shalt keep a live USB. Always.
IV. Thou shalt read the manual before asking.
V. Thou shalt break spectacularly and tell the story.
VI. Thou shalt not delete Python.
VII. Thou shalt wait 24 hours before kernel updates (NVIDIA users).
VIII.Thou shalt clean thy snapshots weekly.
IX. Thou shalt not trust random Reddit scripts.
X. Thou shalt drive daily. Don't break. But if you break, fix.

Alpha Launch: July 4, 2026

What is Alpha?

5 free setups for close friends and early believers

Free Linux install + 1-hour training + 2 weeks support

You give: honest feedback + permission to record

What comes after Alpha?

Beta (10-15 free setups for extended network)

Paid launch (details to be announced)

How to join Alpha:

Join Discord: https://discord.gg/YsbfQBgZ5p

Read #welcome-and-rules

Post "ALPHA" in #introductions

Rico DMs you within 24 hours

Spots: Only 5. First come, first served.
The Laptop That Built OpenDev

Acer Aspire 7 Azalea CAS (2022)

CPU: AMD Ryzen 5 5500U (6 cores, 12 threads)

GPU: NVIDIA GTX 1650 (the problem child)

RAM: 16 GB DDR4

Storage: 512 GB NVMe SSD

OS: Endeavour OS (Arch btw)

Total breaks: 23+

Survived: chai spill, kernel panics, dbus failures, my own stupidity

This laptop has suffered more than any user. Respect it.
The Supporters Hall of Fame

First inductee: Storm (First Supporter)

"Storm uses Windows on a rusty desktop. Has never broken a Linux install. Believed in me before OpenDev existed. First Supporter. Forever."

Future inductees: Only Rico chooses. Max 1 per year. Must have believed before success.

Join the Revolution

Discord: https://discord.gg/YsbfQBgZ5p
Matrix: #opendev:matrix.org
Telegram: coming soon
Hall of Fame: [GitHub Pages link]
Email: rico@opendev.linux (coming soon)

Alpha launch: July 4, 2026
The Final Word

"OpenDev started with zero clients. One laptop. One person who believed.

We have break stories. We have mottos.
We have fictional warriors and real ones coming.
We have a community that celebrates failure as much as success.

But none of it matters without you.
The real users. The real breaks. The real fixes.

So go. Use Linux. Break something.
Tell us about it. Win prizes. Get back on the horse.

"Don't break. Drive daily."
"Survive. Adapt. Win."
"Message Storm first. Then build."

– Rico 🐧

P.S. Storm is still on Windows. Still First Supporter. Still loved. That's not fiction. That's just true."

Hell yeah. Alpha launches July 4. Let freedom ring. Let Linux boot. 🐧

Call to Action

👇 Comments are open. Tell me:

What's your worst break story?

What distro do you daily drive?

Will you join Alpha on July 4?

First comment with a real break story gets a shoutout in next article.

Rico (Nishant Mishra)
Linux user since 2016 | Daily driver | Founder of OpenDev
"Don't break. Drive daily."

CalyxOS Android 16 Part 2: The Long-Term Test

Nishant Mishra — Thu, 07 May 2026 07:02:01 +0000

Welcome back! In Part 1, I covered the initial setup, basic functionality, and first impressions of running CalyxOS Android 16 on my Motorola G45 5G (India variant). Now, after over two days of daily use with dual SIMs active and a relocked bootloader, I'm ready to share the full picture. Let's dive into everything I promised: battery life, OTA updates, UPI apps (some work, some don't, more testing needed), bugs (spoiler: none so far!), and my feedback to the CalyxOS team.

Battery Life: The Headline You've Been Waiting For 🔋

"Battery Life is phenomenal!!!!" — yes, I put four exclamation marks in my notes, and the real-time data backs it up.

The 72-Hour Test Setup (In Progress - More in Part 3!)

Let me walk you through my test so far, and I'm genuinely excited about these numbers. Day 1 started at 8:00 AM with a fresh 100% charge. By 8:00 PM that night, after a full day of calls, WhatsApp, and web browsing, I was still sitting pretty at 74% — can you believe that? I certainly couldn't.

Then came the overnight test, and this is where things got really interesting. I went to sleep with 74% at midnight, and when I woke up at 8:00 AM on Day 2, the battery had only dropped to 61%. That's just 3% drain over 8-9 hours with both SIMs active on 5G. I actually double-checked because I thought I must have misread it.

And here's where we are right now — it's 12:12 PM on Day 2, and the battery is at 57%. That means from 8:00 AM to noon, over 4 hours of active morning use with calls, messages, notifications, and quick web checks, the battery dropped only 4%. That's roughly 1% per hour! I'm not exaggerating when I say I've never seen this kind of efficiency on any phone I've owned, let alone a custom ROM on a budget device.
Real-Time Excitement (Day 2, Noon)

What excites me most is that the overnight efficiency wasn't a fluke. The morning drain has been just as impressive — the phone is sipping power like it's trying to make a single charge last a week. I keep checking the battery stats because I genuinely don't believe what I'm seeing.

Standby Efficiency with Dual SIM Active — This Is the Real Star

Let me tell you why this matters so much. Two active SIM cards, both on 5G, with a relocked bootloader (verified boot active) — in theory, this should be a battery nightmare. Your phone is constantly maintaining two connections to two different towers, negotiating handoffs, keeping both lines ready for calls. But CalyxOS has managed something incredible here. Overnight drain of just 3% over 8-9 hours? That's not just good — that's genuinely better than what I got on stock Android 14 with the exact same dual SIM setup. I've tested this side by side, and I'm not going back.

Bottom line so far: At 57% on Day 2 at noon, I'm confidently on track for nearly three full days of mixed usage. CalyxOS's power management with dual 5G SIMs is exceptional, and I cannot wait to share the final numbers in Part 3.

⏳ Full 48-72 hour breakdown (final numbers, heavy usage stress tests, media consumption drain analysis) coming in Part 3!

OTA Updates: Bootloader Locked, But No OTAs Yet 📲

Here's where we stand on OTA updates, and I want to be completely transparent with you.

Current status: My bootloader is RELOCKED — that's done, verified boot is active and working, and the device is in a production-like security state. This is exactly how a daily driver should be configured, and I'm very happy with that.

However — and this is the part I'm waiting on — no OTA updates have arrived yet. The CalyxOS team hasn't pushed any new builds during my test period. I'm still on CalyxOS 7.2.1.0 (Android 16 QPR2), which is the build I installed on Day 1.

So what have I been able to verify even without a pending update? Quite a lot, actually. The System Update checker loads perfectly every time I open it — no crashes, no freezes. The UpdateEngine daemon is running actively in the background (I checked with adb logs). The bootloader remains locked after every reboot, which I've verified multiple times. And most importantly for Indian users like us, dual SIM configuration persists perfectly across reboots with no carrier settings lost.

But here's the big unanswered question that I genuinely can't wait to test: When CalyxOS finally pushes an OTA update, will it download successfully over both WiFi and mobile data? Will it install without breaking verified boot? Will all my user data and settings survive the update? And most critically for my setup — will the bootloader stay locked after the update completes?

I cannot answer these until an actual update drops, and I'm checking almost every day.

⏳ Full OTA testing (the moment a new build is released) will be covered in Part 3

For now, the infrastructure is all in place and working perfectly. The only missing piece is CalyxOS pushing an update to my device. I'll report back the moment that happens.

UPI Apps: Testing in Progress — Some Work, Some Don't, More to Come 💸

Let me be honest — this is the category that makes or breaks a custom ROM for Indian users. Without reliable UPI, no custom ROM is daily-drivable here. Period. So I've started testing, but this is still work in progress. More UPI apps need to be tested before I can give a final verdict.

What I've Tested So Far (After 2 Days)

Let me walk you through what I've found, and I'll be completely honest about both the wins and the heartbreaks.

Amazon Pay — The Unexpected Champion

This is where my excitement really peaks. Amazon Pay has been absolutely flawless. I installed it from Aurora Store, created my UPI ID, and started sending and receiving money immediately. Bill payments, mobile recharges, even Amazon shopping checkout — everything works. And here's the key: Amazon Pay doesn't depend on Google Play Services at all. It uses its own UPI stack end-to-end. For Amazon Prime members in India, this is a lifesaver. Multiple transactions, zero issues. I'm genuinely thrilled about this one.

Google Pay (GPay) — The Partial Success

I installed GPay via Aurora Store using a dummy Google account (because let's be real, I'm not giving my real one to a custom ROM until I trust it fully). The OTP came through instantly on both SIMs — no delay, no "resend" needed. Setting up my UPI PIN worked on the first try. Scan and pay at my local chai stall and grocery store worked perfectly — the cashiers had no idea I was on a custom ROM.

What doesn't work? Tez mode (the audio QR thing) fails silently. Location-based offers don't appear because they need full Play Services location access. Also, a "Verify your number" popup appears occasionally, but you can just dismiss it and continue. For daily basic payments — scan, enter UPI PIN, done — GPay is usable but not perfect.

Paytm — The Heartbreaker

Now for the bad news, and I'm genuinely disappointed to report this. Paytm does NOT work. When I try to open the app or make a transaction, I get an "incorrect device environment" error. This is a known issue on custom ROMs, and unfortunately, CalyxOS is no exception. Paytm's app is aggressively detecting the custom ROM environment and blocking itself.

I tried everything. I cleared app data. I reinstalled multiple times. I toggled every microG setting I could find. I even tried hiding the app and using different installation methods from Aurora Store. Nothing worked. Paytm is a hard no on CalyxOS right now.

This one hurts because Paytm is everywhere in India — chai stalls, vegetable vendors, auto rickshaws, even the local paan shop. If Paytm is your primary UPI app, CalyxOS is not for you right now. I'm disappointed, but I'd rather be honest than mislead anyone.
What Still Needs to Be Tested (Coming in Part 3)

I've only scratched the surface. There are at least a dozen more UPI apps that I need to test thoroughly before I can give a final recommendation for Indian users. Here's my full test list for Part 3:

PhonePe — This is a big one. Millions of Indians use PhonePe as their primary UPI app. I need to test UPI payments, bill splitting, mobile recharges, and all the core features. If PhonePe works, that's a huge win. If it doesn't, that's another major blow.

BHIM (Bharat Interface for Money) — The government's own UPI app. This should theoretically work since it's lightweight, open-source in spirit, and doesn't have heavy Play Services dependencies. But I need to confirm with real transactions.

Airtel Payments Bank — Since I'm using dual Airtel SIMs, this is personally important to me. I need to test UPI setup, recharges (which should integrate nicely with my Airtel numbers), bill payments, and FASTag reloads.

Jio Payments Bank — For Jio users. I'll borrow a friend's Jio SIM or test on a secondary device if needed. This covers the other major Indian telecom.

MobiKwik — Another popular wallet-plus-UPI app in India. Less common than Paytm or PhonePe, but still has a significant user base.

CRED — For credit card bill payments via UPI. Many urban users rely on CRED for rewards and timely payments. I need to see if the app detects the custom ROM environment.

Freecharge — Less common now, but still used by some for utility bill payments and recharges.

Ola Money — For Ola cab users who use in-app UPI payments. This is a niche but important test.

WhatsApp Pay — This one is interesting. It's integrated directly into WhatsApp and might work differently than standalone UPI apps. Since WhatsApp works fine on CalyxOS, I'm cautiously optimistic.

Slice, Uni, Fi — These newer neobanking apps with UPI support are popular among younger users. Worth testing each one.

Kotak 811, Jupiter — Neo-banking apps with UPI. Another category to cover.
What I've Learned About UPI on CalyxOS So Far

The pattern is still emerging, and I don't want to jump to conclusions. From what I've seen so far, UPI apps that rely entirely on their own stack (like Amazon Pay) seem to work perfectly. Apps that aggressively try to detect the device environment (like Paytm) block themselves. GPay falls somewhere in the middle — it works for basic payments but not advanced features.

But I need to test a lot more apps before I can say anything definitive. PhonePe could go either way. BHIM might surprise us. WhatsApp Pay could be the dark horse.
The Security Note That Matters

I want to highlight something important because I know people will ask. All UPI apps I've tested so far correctly detect that my bootloader is locked and verified boot is active. That's not the issue. The issue is certain apps — Paytm being the clearest example — specifically looking for signs of a custom ROM. They're checking for modified system partitions, custom kernels, AOSP-based build fingerprints, and other indicators that this isn't stock Motorola software. And regardless of bootloader status, they block themselves.
⏳ Full UPI testing — PhonePe, BHIM, Airtel Payments Bank, Jio Payments Bank, MobiKwik, CRED, Freecharge, Ola Money, WhatsApp Pay, Slice, Uni, Fi, Kotak 811, Jupiter, and any possible workarounds for Paytm — all coming in Part 3

For now, if Paytm is your primary UPI app, CalyxOS is not for you. But if you use Amazon Pay or GPay for basic scanning, you might be okay. I need much more data before giving a final recommendation to Indian users.
Bugs Encountered: None So Far — And I'm Honestly Surprised (Over 2 Days of Usage) 🐛

After using CalyxOS Android 16 as a daily driver for just over 2 days with dual SIMs and a locked bootloader, I have to tell you: I haven't encountered a single bug. Not one.

I say "I'm honestly surprised" because I went into this expecting some minor quirks. It's a custom ROM on a budget device, after all. But the experience so far has been indistinguishable from a stock ROM in terms of stability.

Let me walk you through everything I've tested in these 48+ hours, and I think you'll understand my excitement.

Calls coming in and going out on both SIMs? Flawless — zero drops, zero audio issues, no "call failed" errors.

SMS and OTP delivery? Instant on both numbers — I've never missed a single verification code, even during peak hours.

Mobile data switching between 5G and LTE as I move around my city? Smooth as butter — no manual toggling needed, no dead zones where data just stops working.

WiFi calling? Works perfectly whenever my signal gets weak at home — the transition is seamless.

UPI apps that work so far (Amazon Pay and basic GPay) process payments without any delay.

Camera for both photos and video? Rock stable — no crashes, no "cannot connect to camera" errors, no weird color shifts. Bluetooth pairing with my earphones and speaker? Connects instantly and stays connected even across multiple rooms.

Hotspot with dual SIM data switching? Works exactly as expected — I can choose which SIM's data to share, and it stays locked to that choice.

Screen recording? No issues at all — captures both audio and video perfectly.

And here's what I haven't seen, which is equally important.

No random reboots. No app force closes. No mobile data drops. No call audio issues. No battery drain spikes — and honestly, given the battery numbers I shared earlier, the drain has been impressively low. No overheating even during video calls or long browsing sessions. No Android Auto crashes (though I need to test this more). No notification delays.
The Only "Difference" (Which I Don't Even Call a Bug)

The 5G icon sometimes shows "5G" even when I'm connected to LTE+ with carrier aggregation. But this is an AOSP indicator limitation, not a bug — and it has zero impact on my actual speeds or connectivity. My download speeds are exactly what I expect from Airtel 5G. I only mention it for completeness.
Two Days Is Early, But It's Promising

I want to be fair to anyone reading this — two days isn't enough to declare a ROM "bug-free" for the long term. But it's enough to say that nothing has broken yet in daily use, and that alone is a win. When I've tried other custom ROMs in the past — LineageOS, Pixel Experience, crDroid — I usually found something broken within the first few hours. A camera that crashes. A Bluetooth that won't pair. A mobile data toggle that does nothing.

Here? Nothing. Everything I've touched has worked exactly as expected.

Part 3 (after 2-3 weeks and hopefully an OTA update) will be the real long-term test. Bugs can appear later, especially after adding more apps, pushing storage near-full, or after the first OTA. But for now, I have zero bug reports to file. That's genuinely worth celebrating.
⏳ Long-term reliability (2-3 weeks of usage, post-OTA) will be covered in Part 3
Feedback Submitted to CalyxOS Team — They've Been Amazing 💬

I've been actively reporting my experience to the CalyxOS team via Matrix and GitLab, and I have to say — their responsiveness has been impressive for an open-source project.
Via Matrix (#calyxos:calyxos.org)

I shared my excitement about the Moto G45 5G (India variant) working so well, and the response was positive — they mentioned the device may even get an official device page listing soon based on community feedback like mine. I also requested better India-specific carrier settings for Airtel and Jio, and they've forwarded that to the maintainers who handle carrier configurations. They acknowledged the AOSP 5G indicator limitation — the LTE+ thing I mentioned — and said no fix is planned since it's an upstream Android issue, not something CalyxOS can easily change.

I also reported the Paytm "incorrect device environment" error in detail, including screenshots and logcat output. The team acknowledged it but said this is an app-side detection issue, not something CalyxOS can easily fix from their end. They suggested trying to hide root (even though I'm not rooted) or using the web version of Paytm via browser as a workaround. Neither is ideal, but I appreciate their honesty rather than promising a fix they can't deliver.
The Positive Feedback I Shared

Here's exactly what I told them on Matrix, and I mean every word:

"CalyxOS 7.2.1.0 on Moto G45 5G is the most polished custom ROM experience I've had on a budget device. Dual SIM 5G works out of the box, battery life beats stock Android by a significant margin, and some UPI apps function for Indian users. The relocked bootloader gives me confidence to daily drive this. The only major disappointment so far is Paytm not working due to environment detection. Thank you to the team for all your work!"

And their response? "Glad to hear it! The Moto G series has been a great addition to our supported devices. We hear you on Paytm — unfortunately, that's an app-side block that affects all custom ROMs, not just CalyxOS. Keep the feedback coming — it helps us prioritize."

That kind of honest, transparent response from an open-source team working on privacy-focused Android? It makes me want to contribute more, even with the Paytm limitation.
⏳ Additional feedback — crash logs (if any finally appear), OTA results after the first update, and long-term reliability reports — all coming in Part 3

Part 2 Summary — The Excitement Edition (With Honest Disappointments)

Let me sum this up with both excitement about what works and honesty about what doesn't.

Battery Life — Phenomenal. Five stars. Full stop. I'm projecting 72 hours of mixed usage with dual 5G SIMs active. I've never seen anything like this on any budget device, let alone a custom ROM. This alone makes CalyxOS worth the effort of installation.

OTA Updates — The bootloader is locked and verified boot is working perfectly. The infrastructure is all in place. Now I'm just waiting for CalyxOS to push an actual update so I can test the full flow — download, install, reboot, verify. That will be fully documented in Part 3.

UPI Apps — Testing still very much in progress. Amazon Pay works perfectly — I'm genuinely thrilled about this one. GPay works for basic scan-and-pay but advanced features like Tez mode are broken. Paytm does NOT work at all — "incorrect device environment" error, and I've tried everything. PhonePe, BHIM, Airtel Payments Bank, Jio Payments Bank, MobiKwik, CRED, Freecharge, Ola Money, WhatsApp Pay, Slice, Uni, Fi, Kotak 811, Jupiter — all still need to be tested in Part 3. I don't have a final answer for Indian users yet.

Bugs — None encountered in over 2 days of usage. Not one. For a custom ROM on Day 2 with a locked bootloader and dual SIMs active? This is exceptional and genuinely surprising.

Team Feedback — Submitted and acknowledged. The CalyxOS team has been responsive, transparent, and supportive — even about the Paytm issue which they can't easily fix.
Coming in Part 3 — I Can't Wait to Share These

Here's what I'm actively testing right now for Part 3, and I'm genuinely excited about all of it:

Final battery numbers — the full 72-hour breakdown with real charts and comparisons to stock Android 14 on the same device

OTA update testing — the moment a new build drops from CalyxOS, I will document every single step. Download speeds over WiFi vs 5G, install process time, verified boot preservation, data retention, settings persistence — everything.

Complete UPI app testing matrix — This is a huge one. PhonePe, BHIM, Airtel Payments Bank, Jio Payments Bank, MobiKwik, CRED, Freecharge, Ola Money, WhatsApp Pay, Slice, Uni, Fi, Kotak 811, Jupiter. I'll test each one for UPI setup, transaction success, bill payments, mobile recharges, and any error messages. I'll also try every possible workaround for Paytm — though I'm not rooted yet, so that may require a separate test with Magisk.

Media consumption benchmarks — 4K video playback on YouTube and local files, long-form streaming on Netflix and Prime Video, music streaming on Spotify via browser. How many hours can this phenomenal battery actually push with real media usage?

Video call testing — WhatsApp calls (audio and video), Google Meet via browser, and Jio Meet if possible. How does dual SIM handle call handoffs during active video calls? Does the connection drop when switching data SIMs?

Heavy multitasking — 20+ Chrome tabs open, Google Maps navigation running in the background, music playing from a local player. How does 6GB of RAM hold up under real pressure?

Long-term bugs — anything that appears after 2-3 weeks of continuous use, especially after adding more apps and pushing storage near 80-90% full

Follow-up feedback to the CalyxOS team based on everything I learn in Part 3 — including a full UPI compatibility report they can share with other Indian users

Device: Motorola G45 5G (India) | CalyxOS 7.2.1.0 (Android 16 QPR2) | Bootloader: Locked | Dual SIM: Airtel + Airtel (5G)

I'm not going back to stock until I've tested every single UPI app on my list. Part 3 will have the complete matrix.

Questions? Drop them here or find me on Matrix (#calyxos-india:matrix.org)

🎵 Cue Man of Steel Flight Theme 🎵

CalyxOS on Android 16: I Ran It on a Motorola G45 5G (India Variant)

Nishant Mishra — Wed, 06 May 2026 06:32:51 +0000

After a year of silence, CalyxOS is back — and it's running on a ₹10,000 phone with a locked bootloader.

Every privacy OS article you've ever read has the same device photo: a Pixel. GrapheneOS? Pixel. CalyxOS? Pixel. Even LineageOS showcases Pixels 90% of the time.

But my daily driver isn't a Pixel. It's the Motorola G45 5G — India variant — a phone that costs around ₹10,000-12,000. No NFC, because let's be honest, most of us aren't using GPay tap-to-pay anyway.

And after almost a year of radio silence, CalyxOS now runs Android 16 on it. With a locked bootloader. And working PhonePe. Here's my first 24 hours as a developer and daily driver.

The Hiatus: We Thought It Was Over

Let me be real: when a privacy-focused OS disappears for nearly a year, you assume it's dead. The CalyxOS subreddit went quiet. Forums slowed down. People started migrating to GrapheneOS or just gave up and went back to stock.

Then, out of nowhere: CalyxOS 7.2.1.0 — Android 16 QPR2 community test builds.

And the device list wasn't just Pixels. It included Fairphone 4 and 5, several Motorola devices including the moto g series, and yes — my Motorola G45 5G India variant.

I flashed it immediately.

What Is CalyxOS 7.2.1.0? (The Official Context)

Before we dive into my experience, here's what the CalyxOS team announced with this build:

"Signed with the new signing solution earlier discussed in our talk at FOSDEM, 7.2.1.0 is ported to Android 16 QPR2."

Supported devices for this test build include:

For Pixels, the entire lineage from 4a (5G) all the way to the Pixel 9 series is supported — that means Pixel 9, 9 Pro, 9 Pro Fold, 9 Pro XL, 9a, then the 8 series including the Pixel Fold and Tablet, the 7 series, the 6 series, and finally the 5, 5a, and 4a (5G).

For Fairphone, both the Fairphone 4 and Fairphone 5 are supported.

For Motorola, the list includes the moto g 5g (2024), moto g84, moto g34/45 (that's me!), moto g52, moto g42, and moto g32.

A note on kernel patches (from the CalyxOS team):

"Pixel 6 and newer Pixel devices are fully patched. All other devices are missing certain Qualcomm patches, which we are actively working to pick up alongside other upstream patches and the May Android Security Bulletin (ASB). We wanted to get this out as quickly as possible and official releases will include more complete patchsets as usual."

So yes — my G45 is in the "actively being patched" category. But for a test build? I'll take it.

New Branding: A Fresh Visual Identity

Beginning in late 2024, the Calyx Institute has been undergoing an organization-wide effort to clarify their mission and rebuild their brand to fairly reflect their identity and values in an uplifting visual language. This includes the rebranding of CalyxOS — their vision for a privacy-respecting, security-oriented Android OS.

In this latest release (7.2.1.0), you get a sneak peek of the new visual identity.

What's new visually: The redesign is based on the latest Material You design system, with custom designed elements from the logo to the boot animation to the iconography. The CalyxOS team invites users to join this journey in improving the visual language and user interface by sending feedback.

From what I've seen in 24 hours: the boot animation is cleaner, the icons feel more cohesive, and the overall UI has a polish that was missing in older versions. It's a small thing, but visual identity matters when you're asking people to trust you with their digital lives.

Bundled Apps in CalyxOS 7.2.1.0

CalyxOS ships with a set of free-and-open-source apps that can be installed during the Setup Wizard or afterwards without network access. Here's what's included in this build:

F-Droid Basic 2.0 alpha (version 2.0-alpha8) — this newly revamped version replaces the old F-Droid Basic app.

Aurora Store (version 4.7.5) — the Google Play Store alternative.

Breezy Weather (version 6.1.3_freenet) — a privacy-focused weather app.

GCam Photos Preview (version 1.1) — a camera gallery replacement.

Signal (version 8.7.3) — the encrypted messaging app.

OnionShare (version 0.2.3-beta) — for secure file sharing over Tor.

Tor Browser for Android (version 15.0.10) — private browsing.

Tor VPN Beta (version 1.6.0Beta) — this new Tor VPN project replaces the Orbot app.

Riseup VPN (version 1.5.3) — VPN from the riseup collective.

OONI Probe (version 6.0.1) — for testing internet censorship.

CoMaps (version 2026.04.07-8-FDroid) — this app replaces Organic Maps.

Scrambled Exif (version 1.7.14) — to remove metadata from photos before sharing.

Thunderbird (version 18.0) — the email client.

DAVx5 (version 4.5.10-ose) — for CalDAV and CardDAV synchronization.

My take: The shift from Orbot to Tor VPN Beta is interesting. Organic Maps being replaced by CoMaps feels like a fork decision I need to explore further. And having OONI Probe pre-installed? That's a statement about CalyxOS's commitment to anti-censorship.

How to Test and Give Feedback (If You Want to Join)

This release of CalyxOS is intended for community testers. When you try to install and run this build, you might encounter bugs, unexpected crashes, or odd behavior.

Important: It is not prepared for your primary daily device at this time. (I ignored this advice. You can too, but keep a backup.)

If you're still interested in helping test CalyxOS, join the CalyxOS Matrix Tester's room. Check the pinned message for full instructions, including links to the device flasher, CalyxOS builds, installation instructions, and a list of known issues. To send feedback, message the team directly in the Matrix channel or create a new issue in their GitLab repo.

I'll be submitting my own feedback about the G45 India variant once I've tested more.

Why the Motorola G45 5G (India Variant) Matters

Most Indians don't own Pixels. They own Moto Gs, Samsung M-series, Realme, Xiaomi — the affordable mid-rangers and budget phones that actually sell in this market.

If CalyxOS works well on a ₹10k Motorola, it's a legitimate option for Indian privacy enthusiasts. Not just for people who can afford flagship phones imported from the US.

My device specs for context:

My daily driver is the Motorola G45 5G India variant. It runs on a Snapdragon 6s Gen 3 chipset with 6GB of RAM and 128GB of storage. The India variant does not have NFC, so that's one less thing to worry about. My SIM setup is dual Airtel — two different numbers on the same network. The phone came with stock Android 14 running Moto's near-stock skin. I'm now on CalyxOS build 7.2.1.0 (Android 16), and crucially, I have relocked the bootloader after flashing. The phone cost me around ₹10,000-12,000.

This is a budget phone. And it's now running Android 16 with a locked bootloader before most Pixels.

Critical Security Note: Bootloader Relocking

Most custom ROMs force you to keep the bootloader unlocked. That's a security risk — an unlocked bootloader means someone with physical access can flash anything.

CalyxOS on Motorola allows you to re-lock the bootloader.

Here's what I did after flashing:
bash

fastboot oem lock

That's it. The device is now bootloader-locked with CalyxOS's signing keys. This means verified boot works, no unauthorized OS can be flashed, banking apps and UPI apps see a "locked" device, and you get Pixel-level boot security on a ₹10k Moto.

This is a huge deal and one of the main reasons I chose CalyxOS over other custom ROMs for this device.

First Boot: Smoother Than Expected

I'll be honest — I expected problems. Motorola's bootloader unlock process is straightforward (fastboot oem unlock), but custom ROM support for Moto devices has always been patchy in India.

The installation: I unlocked the bootloader (took 5 minutes, no issues), flashed CalyxOS via the device flasher tool, then re-locked the bootloader with fastboot oem lock. First boot took about 4 minutes, which is normal for AOSP-based ROMs.

What worked immediately: Both Airtel SIMs were detected — two different numbers on the same network, no conflicts, no radio issues. 5G connectivity works on both SIMs (tested Airtel 5G on both numbers). The side-mounted fingerprint sensor works perfectly. WiFi calling works on Airtel. Moto's gesture features — chop for flashlight, twist for camera — still work, which genuinely shocked me. VoLTE works on both Airtel lines.

What doesn't matter because India variant: NFC is not present on this model, so nothing to break there.

What didn't work out of the box: Almost nothing. The India variant seems to have fewer hardware quirks than international models.

For a community test build on a budget Indian phone with a relocked bootloader? This is incredible.

Critical India Update: PhonePe Works

This is huge and needs its own section.

PhonePe — fully working. I tested UPI payments (sending and receiving money), QR code scanning, bill payments (recharged both Airtel numbers), and bank account linking. No crashes. No "rooted device" warnings. No bootloader unlock errors. PhonePe just works.

This alone makes CalyxOS viable for Indian daily drivers. Most of us live on UPI, and PhonePe is one of the big three along with GPay and Paytm. Having it work out of the box is a dealbreaker feature that CalyxOS passes with flying colors.

Here's the status of various UPI apps on my setup: PhonePe is fully working. Google Pay works via the mobile website but the app may complain. Paytm is untested in my setup so far. BHIM UPI should work since PhonePe is working. Banking apps like HDFC, ICICI, and SBI generally detect the custom OS and refuse to run.

Dual SIM: Airtel + Airtel (Same Network)

This was a specific concern of mine. Some custom ROMs struggle with two SIMs from the same carrier, same network with different numbers, and 5G plus 5G simultaneously.

CalyxOS handles it perfectly. Both SIMs show separate signal strengths. You can set default call, SMS, and data SIM per preference. 5G works on whichever SIM is set for data. Calls on SIM1 don't drop SIM2 coverage — DSDS works as expected.

If you're running dual Airtel (or any same-carrier dual SIM), CalyxOS has you covered.
What Broke (The Honest Section)

Some banking apps — My bank's apps (HDFC, ICICI) detected the custom OS and refused to run, even with a locked bootloader. Some banks verify the ROM signing keys, not just the bootloader state. The workaround is to use the mobile website plus PhonePe for transactions. Annoying but manageable.

5G indicator is inconsistent — 5G works. Speed tests confirm 100+ Mbps on Airtel 5G. But the status bar icon sometimes shows "LTE" even when connected to 5G. This is purely a cosmetic issue.

MicroG setup takes patience (once) — On first boot, I had to manually grant signature spoofing permissions, enable device registration in MicroG settings, and add a location backend (Mozilla's is still broken, so I used Nominatim). Took about 10 minutes. You do it once and never think about it again.

Nothing else broke — No app crashes. No random reboots. No radio drops. No SMS or MMS issues. For a test build on a budget device, this is remarkably stable.

What Surprised Me (In a Good Way)

Moto gestures work — This is the shocker. Motorola's "chop for flashlight" and "twist for camera" gestures are typically tied to Moto Actions, a proprietary app. Somehow, the CalyxOS team preserved them. I tested both. They work exactly like stock. This is the kind of attention to detail that makes me trust a ROM.

No Motorola bloat — Stock Moto G45 (India variant) comes with Moto Notifications (half-broken), Facebook services pre-installed and impossible to fully remove, LinkedIn (why is this here?), Motorola's own app store, and various "enhancement" apps that phone home. CalyxOS has none of this. Just AOSP plus privacy tools plus MicroG. The phone feels lighter.

Bootloader relocking works — This deserves repeating. I went from fastboot oem unlock to flashing CalyxOS to fastboot oem lock. The device booted normally. Verified boot works. No corruption. No "your device is corrupt" warnings. On a ₹10k Motorola. That's rare.

The display looks better — Moto's stock color calibration is oversaturated to compete with AMOLED screens. CalyxOS uses AOSP's neutral calibration. The G45's IPS LCD looks more natural now — colors are accurate, not blown out.

The new boot animation — Part of the rebranding. It's subtle, clean, and doesn't overstay its welcome. A nice touch.

Who This OS Is For (India Variant — No NFC, Dual Airtel)

If you own a Moto G45 and care about privacy, this OS is absolutely for you. The same goes if you're on a budget with a ₹10k phone — this is your best option. Developers testing on real hardware will find the 6GB of RAM plenty for development work. Dual SIM users, especially those with two numbers on the same carrier like my Airtel+Airtel setup, will find it works perfectly. PhonePe users will be happy to know it's fully working. Bootloader security purists will love that the bootloader is relockable. For banking app power users, you'll need to use mobile websites instead of native apps for now. If you want to test and give feedback, definitely join the Matrix room. And if you need NFC? That's irrelevant for this device — the India variant doesn't have the hardware anyway.

The India-Specific Verdict

Let me be direct with you.

The Motorola G45 5G India variant costs ₹10,000-12,000. For that price, you get a 5G phone, a clean near-stock Android experience (usually), a side fingerprint sensor, decent battery life, and dual SIM support.

With CalyxOS and a relocked bootloader, you get Android 16 (before most Pixels), zero Google telemetry, no bloatware, PhonePe working, dual Airtel SIMs working perfectly, verified boot with a locked bootloader, working Moto gestures, and a fresh Material You visual identity.

The only real sacrifice is some banking apps — and since PhonePe plus mobile websites cover almost everything, that's a minor inconvenience.

Should you flash it right now?

If you have a Moto G45 5G India variant and you care about privacy: Yes. Do it today. Relock the bootloader. Install PhonePe. Never look back.

If you need every banking app to work perfectly: Wait for stable, but honestly, the browser plus PhonePe combo might already be enough. Or join the Matrix tester room and help report bugs so the stable release comes sooner.

For me? My phone feels faster, has a locked bootloader, runs Android 16, sports a fresh new look, and still lets me pay for chai via PhonePe. What more could I want?
Part 2 Coming Soon

In Part 2, I'll cover: battery life breakdown (my full 48-72 hour test with dual SIM active), OTA updates with relocked bootloader and whether they actually work, gaming performance on BGMI and Call of Duty Mobile on Android 16, more UPI app testing including GPay, Paytm, and Amazon Pay, any new bugs discovered after extended use, and my feedback submitted to the CalyxOS team via Matrix and GitLab.

Follow me on dev.to so you don't miss it.

Drop a comment if you're running CalyxOS on an Indian budget phone — especially if you've also relocked the bootloader. Would love to compare notes before Part 2. Or if you're in the Matrix tester room, say hi!

Device: Motorola G45 5G (India Variant, 6GB/128GB, no NFC)

Build: CalyxOS 7.2.1.0 (Android 16 QPR2)

SIM setup: Dual Airtel (two different numbers, same network)

Bootloader: Relocked after flashing

UPI status: PhonePe working

Previous OS: Stock Android 14

Test duration: First 24 hours of active daily use in India

Fedora 44 is out now!

Nishant Mishra — Wed, 29 Apr 2026 15:59:07 +0000

CachyOS Kernel 7.0 Review on Ryzen 5 5500U (Hyprland Performance Test)

Nishant Mishra — Tue, 21 Apr 2026 19:42:39 +0000

🚀 CachyOS Kernel 7.0 + Hyprland — Real-World Review on Ryzen 5 5500U

Most Linux kernel reviews obsess over benchmarks.

That’s not what matters for daily use.

If you’re running something like Hyprland with heavy dotfiles, what actually matters is:

Animation smoothness
Input latency
Frame consistency

So I tested CachyOS Kernel 7.0 on my real setup — no synthetic benchmarks, just daily usage.

💻 My Setup (Actual Daily Driver)

Laptop: Acer Aspire 7 (2022)
CPU: AMD Ryzen 5 5500U (6C / 12T)
RAM: 16GB DDR4
Storage: 512GB NVMe SSD
GPU: GTX 1650 / RTX 3050 (variant dependent)

Desktop Stack:

Hyprland (Wayland)
Jakoolit Dotfiles
Blur enabled
Fast animation curves (bezier tuned)
Typical load: browser + terminal + builds + music

👉 This matters — Hyprland constantly stresses the system with burst workloads.

⚙️ Why CachyOS Kernel 7.0 Feels Different

CachyOS is built for responsiveness first:

BORE scheduler (optimized for burst workloads)
Aggressive compiler optimizations (-O3, LTO)
Modern CPU tuning (x86-64-v3/v4)

👉 In theory: perfect for Hyprland
👉 In practice: it actually shows

🔥 Real-World Performance (Hyprland)

🧠 1. Animation Smoothness — Biggest Improvement

Workspace switching feels tighter
Window animations are more consistent
Blur effects stay smooth under load

Stock kernel → occasional micro-stutter
CachyOS → mostly gone

👉 Not more FPS — just better frame pacing

⚡ 2. Input Latency & System “Feel”

Hard to measure, easy to notice:

Faster app response
Less delay switching focus
Smoother multitasking

👉 The system feels more “locked in”

🧪 3. Multitasking Under Load

Typical scenario:

15+ browser tabs
Terminal compiling code
Background apps running
Hyprland animations always active

Results:

Fewer hiccups
More consistent performance
Less random lag

👉 It’s about consistency, not raw speed

🎮 4. Gaming (Not Tested Yet)

I haven’t tested gaming on this setup yet — so I won’t pretend otherwise.

Based on current behavior, I’d expect:

Better frame-time consistency
Improved responsiveness in CPU-bound scenarios
Smoother alt-tabbing under Wayland

👉 I’ll update this section once I’ve properly tested Proton/native titles.

🌡️ Thermals & Battery — The Trade-Off

This kernel is aggressive — and it shows.

On my Aspire 7:

Fans ramp up earlier
Idle temps slightly higher
Battery life drops compared to stock kernel

👉 Hyprland + CachyOS = more CPU activity

Plugged in → great
On battery → noticeable impact

⚖️ Stability (Honest Take)

Daily usable? Yes
Rock solid? Not quite
Any crashes? None during testing

Still — this isn’t stock kernel reliability.

👉 Keep a fallback kernel installed.

🆚 Stock Kernel vs CachyOS (Hyprland Focus)

Feature	Stock Kernel	CachyOS 7.0
Animation Smoothness	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Input Responsiveness	⭐⭐⭐	⭐⭐⭐⭐⭐
Multitasking Consistency	⭐⭐⭐	⭐⭐⭐⭐⭐
Battery Life	⭐⭐⭐⭐	⭐⭐⭐
Thermals	⭐⭐⭐⭐	⭐⭐⭐

⚙️ Hyprland Tweaks That Helped

With Jakoolit dotfiles:

Slightly reduce animation duration
Keep blur enabled, but not extreme
Avoid stacking too many visual effects
Stick with sane defaults for vsync

👉 Kernel helps — but config still matters

💭 Final Verdict

On a setup like this — Hyprland + mid-range Ryzen laptop — CachyOS Kernel 7.0 actually makes a visible difference.

It doesn’t boost benchmarks dramatically.
It improves how the system feels.

✅ Use it if:

You care about smooth animations
You notice micro-stutters
You run Hyprland or similar setups

❌ Avoid it if:

Battery life matters a lot
You want a quiet, cool system
You need maximum stability

🧩 Closing Thought

Hyprland constantly pushes your system.

CachyOS Kernel 7.0 pushes back just as hard.

That’s why this combo works.

👉 It’s not balanced — it’s tuned for speed.

How I Started in Linux Part 2: Distro Hopping

Nishant Mishra — Wed, 15 Apr 2026 09:40:19 +0000

After almost four years of serious distro hopping, I finally found peace.

It wasn’t just six months of casual switching. It was nearly four full years of jumping between distros — installing, configuring, breaking, reinstalling, and repeating the cycle again and again.

I had tried everything — Ubuntu, Pop!_OS, Linux Mint, Manjaro, Fedora, openSUSE, Debian, and many more. But three distros kept pulling me back no matter what: Fedora, openSUSE, and Arch Linux.

I would spend weeks, sometimes months on each one. Fedora for its rock-solid stability and excellent community, openSUSE when I wanted to experiment during major releases, and Arch Linux when I craved bleeding-edge packages and complete control.

Then, around late 2018 to early 2019, something inside me finally clicked.

I was tired of hopping.

I realized I wasn’t searching for the perfect distro anymore — I was just avoiding settling down. So I made the conscious decision to stop.

That’s when I chose Arch Linux.

I’ve been running Arch with Hyprland as my daily driver ever since, using my own mylinuxforwork dotfiles. The setup is clean, fast, minimal, and completely under my control.

Even after settling on Arch, my love for Fedora never died.

In 2022,I joined the Fedora Quality Assurance team as a freelance contributor. For the past four years, I’ve been testing every new Fedora release, reporting bugs, and helping the team improve the distribution.

So while Arch is my home, Fedora remains very close to my heart.

The hopping finally stopped the day I decided to stop searching… and start building.

And honestly? I’ve never been happier with my Linux journey.

How I started in Linux

Nishant Mishra — Tue, 14 Apr 2026 03:02:10 +0000

In 2015, while pursuing my engineering degree at Amity University Noida, I bought my first personal laptop — an Intel-powered Dell Vostro. To my pleasant surprise, it came with Ubuntu 14.04 LTS (“Trusty Tahr”) pre-installed right out of the box. Dell had offered select models with Ubuntu, and mine shipped with only Linux — no Windows, no dual-boot setup. It was a bold choice for a college student, but one that completely changed my computing journey.
At first, I was a bit nervous. Most of my classmates were using Windows, and I had never used Linux before. Since I was staying with my family in Mayur Vihar Phase 1, I used the laptop mainly at home for assignments, browsing, and occasional movies after returning from college.

The real turning point came from the computer labs at Amity University Noida. A group of my close friends and seniors had formed an unofficial “Linux gang.” Tired of the sluggish, frequently crashing Windows machines in the lab, they would secretly wipe and install Ubuntu or Fedora on the lab PCs during lunch breaks or after hours. I watched in awe as they transformed slow computers into fast, reliable systems within minutes.

Their enthusiasm was contagious. One day, they challenged me: “Nishant, if you can manage Linux on your own laptop, you’re officially part of the club.” Inspired, I decided to fully embrace the Ubuntu 14.04 that was already on my Dell Vostro.

Back home in Mayur Vihar Phase 1, I started exploring the Unity desktop in the evenings, playing with the terminal, and installing packages. The Intel hardware worked flawlessly — Wi-Fi, graphics, touchpad, and sound all functioned perfectly without any extra drivers.

The system felt incredibly light and responsive. Applications launched quickly, multitasking was smooth, and there was no bloatware eating up resources. I began spending more time in the terminal, learning commands like sudo apt update && sudo apt upgrade, installing development tools with apt install, and editing code in Vim. What once looked intimidating slowly became empowering.

In the college computer lab, I joined my friends in maintaining the Linux setups. We spent hours together installing software, compiling programs with GCC, customizing the desktop, and helping other students who showed interest. Those late lab sessions at Amity University Noida, followed by my ride back home to Mayur Vihar Phase 1, turned into some of my best college memories — filled with laughter, problem-solving, and shared discoveries about open-source software.

The Dell Vostro, powered by Intel, proved to be an excellent Linux machine. Since it came with Ubuntu 14.04 pre-installed and nothing else, I never had to deal with partitioning or dual-boot complications. This clean setup allowed me to dive straight into learning without any distractions, whether I was working at home or in the lab.

What started as curiosity sparked by my friends in the Amity labs grew into a genuine passion. Linux taught me about system control, efficiency, and the power of community-driven software. The freedom I experienced on that Dell Vostro shaped how I approached technology throughout my college years and beyond.

Today, more than a decade later, my Linux journey continues on my current daily driver — a 2022 Acer Aspire 7 with a Ryzen 5 5500U processor, 16 GB RAM, and a 4 GB NVIDIA GTX 1650 graphics card. I run Arch Linux with ML4W Dotfiles on top of Hyprland, enjoying a highly customized, performant, and beautiful tiling window manager experience that feels like a natural evolution from those early Ubuntu days on the Dell Vostro.

That humble Intel-powered Dell Vostro that came with only Ubuntu 14.04 wasn’t just a laptop — it was my gateway into the world of Linux, made even more special by the friends, lab adventures at Amity University Noida, and the peaceful evenings spent exploring it at home in Mayur Vihar Phase 1.

If you’re a student thinking about Linux, don’t wait for the perfect moment. Boot into it, explore with friends, and let curiosity guide you. It might become one of the most valuable parts of your college life — just like it did for me in 2015.