From the beginning, I wanted Gunam to feel different.

My goal has been simple: configuring Gunam should be one of the easiest parts of integrating it into an application. Developers should focus on what they want to monitor, not on how the library is implemented internally.

That idea became the foundation of Gunam's configuration layer.

A Simple Goal

The design objective was clear from day one:

Developers should only choose the sensors they want to monitor and how those sensors should be monitored.

Everything else should be handled by Gunam.

To achieve that, the configuration layer is built around three core concepts.

Sensor Kind

The first decision is what you want to monitor.

Every deployment is different. A kiosk, an industrial machine, or an Android TV box will have different monitoring requirements. Not every application needs CPU, battery, network, storage, or memory metrics.

Instead of collecting everything by default, Gunam allows developers to explicitly choose the sensors they care about.

This keeps the configuration simple while giving engineers complete control over the data they collect.

Polling Strategy

Not every sensor should be polled the same way.

Some information needs to be collected at regular intervals, while other events are only meaningful when they change or when an application explicitly requests them.

For example:

• CPU usage may be collected every few seconds.

• Network connectivity may be checked every minute.

• Battery level may only be reported when its value changes.

• Some sensors may only be queried on demand.

Every sensor tells a different story, so Gunam allows each one to have its own polling strategy instead of forcing a single approach across the entire system.

Transport

Once the sensors and polling strategies have been configured, the final step is deciding where the collected data should go.

Different applications have different requirements. Some may send telemetry to a REST API, others may stream data over TCP, while some deployments may simply collect information locally without transmitting anything.

Rather than enforcing a single transport mechanism, Gunam gives developers the flexibility to choose the communication strategy that best fits their system.

This layer also lays the foundation for higher-level capabilities such as alerting, analytics, machine learning pipelines, and remote fleet management.

Looking Ahead

This configuration layer is only the first step in Gunam's architecture.

Once configuration is complete, the next challenge is deciding how those sensors should execute efficiently. That's where thread management comes in, followed by thread observability so developers can understand exactly what Gunam is doing at runtime.

In the next article, I'll dive deeper into the second layer of Gunam and explain how I'm approaching thread management while keeping the developer experience simple.

If you'd like to follow the project's progress or contribute, you can find Gunam on GitHub:

GitHub: https://github.com/IAmInYourKernel/gunam

I'm building Gunam, a cloud-free, FFI-first Rust agent for on-premises device management — OTA updates, telemetry, panic-safe operation, for environments where you can't assume a server is even reachable. Early on, the design seemed obvious: detect what OS you're running on, then run the OTA strategy that matches that OS.

Previously, when I was creating the device class to get the access control of the system, I accidentally never asked the correct question to myself: Is the device class enough to give you complete access?
enum DeviceClass { Linux, Android, Windows, Mac, }

Detect Linux → use GRUB-style A/B slot switching. Detect Android → use Android's update mechanisms. Simple dispatch table. I was ready to build the OTA logic directly on top of this.

The actual question comes, "WHO CONTROLLS THE BOOT LOADER ?"

The assumption that almost created a catastrophe

Here's the part I'd glossed over: that HAL is only reachable if you're the one who built the OS image. If you're an OEM flashing your own AOSP build, you can talk to it. If you're a regular app — or a .so library sitting inside a regular app, which is exactly what Gunam is — you have zero access to it. Not "restricted access." Zero. No permission grants it. It's locked away from userspace apps by design, for the same reason you don't want any random app able to flip your boot partition.

So device class doesn't actually tell you whether bootloader-level A/B is available. It tells you the OS family. Whether you can do anything with that OS's update mechanism depends entirely on how the device was deployed — whether you're the OEM or just an app running on stock hardware.

If I'd built the OTA dispatch logic directly on DeviceClass, the code would have compiled fine, looked correct, and then silently attempted bootloader operations it had no permission to perform — on whichever Android device someone actually deployed Gunam to. That's the worst kind of bug: invisible until a real user hits it. Cost created the catastrophe .

The solution I got

Device classes answer what OS I am, which was not enough to understand how much write and read access I actually have. Here at this point, the introduction of access tiers comes.
enum AccessTier { ImageLevel, PrivilegedSystem, AppLevel, ReadOnly }.
The same OS can give you different access. As Gunam does telemetry and OTA. Without proper access, the system will give us a permission error, which will block the outcome we want .

A Linux kiosk box you flash yourself is Image level. A rooted Android device is Privilege level. A stock Android app — which is most real-world Android deployments — is App level. And critically, there's a tier for "I don't actually know, or I have no access"—read—only— which exists specifically so the agent can say "I can't safely act here" instead of guessing and failing silently later.

What this actually bought me

Beyond avoiding the bug: every OTA-related function in Gunam now has to explicitly handle all four tiers, because the type system makes it impossible to forget one. It goes deep into every layer and asks for permission before it returns the final access control.

The main goal of building Gunam was not only to provide telemetry but to build a system that is fault-tolerant. Managing On-premises devices is hard when the system is not ready to handle errors.

This blog is not just about sharing the experience but to remind myself that when you have all the answers in the world... Asking the right question at the right time matters.

If you'd like to follow the project's progress or contribute, you can find Gunam on GitHub:

GitHub: https://github.com/IAmInYourKernel/gunam

Reading CPU and battery information sounds very easy. You search for a library or ask AI for a better and quicker way to get the data for display.

Using AI is exactly what I did.

Within a few seconds, I found /proc/stat and /sys/class/power_supply.

I quickly realized that writing the code was no longer the difficult part. Years ago, developers spent hours searching Google, reading documentation, and browsing Stack Overflow. Today, we ask AI, and it usually gives us a working starting point within seconds.

The real challenge was understanding the operating system itself.

CPU: Reading Numbers

On Linux, CPU statistics are exposed through /proc/stat.

The moment you read the file, you'll see something like:

10132153 290696 3084719 46828483 16683 0 25195 0

At first glance, these numbers don't mean much.

What I learned is that they are cumulative counters that have been increasing since the system booted. They are not CPU percentages.

To calculate CPU usage, you have to:

• Read the counters.

• Wait for a short interval.

• Read them again.

• Calculate the difference between the two readings.

• Determine how much of that difference represents busy time.

Operating systems rarely give you exactly what you want. Instead, they expose low-level primitives, and it becomes your responsibility to derive the higher-level metrics from them.

Battery: When the Environment Becomes the Problem

Getting battery information looked even easier.

Linux exposes battery information under /sys/class/power_supply.

I wrote code to locate the battery, read its capacity, charging state, and cycle count.

Everything looked correct.

Then I tested it.

Nothing worked.

The reason wasn't my code.

I was running inside WSL on a Windows laptop.

WSL is a compatibility layer rather than a full Linux installation running directly on the hardware. There is no real Linux battery device inside /sys/class/power_supply. The battery belongs to Windows, not to the Linux environment running under WSL.

This taught me an important lesson.

Sometimes your code is perfectly correct, but the environment simply cannot provide the information you're asking for.

Key Insight: Details Matter

To be honest, I didn't write most of the operating system or filesystem-related code from scratch. AI generated a significant portion of it.

What AI couldn't do was explain why the battery wasn't available in WSL. It couldn't magically expose hardware that the operating system itself wasn't exposing.

That realization made me think.

As engineers, we often become so excited about reaching the final outcome that we overlook the small details that determine whether our solution actually works.

In my case, I overlooked the execution environment.

Similarly, AI is only as useful as the context we provide. If we ignore important details that are still our responsibility—such as the operating system, the execution environment, or hardware limitations—AI cannot compensate for those gaps.

AI can change how we write code.

It cannot change how we think.

Today, generating code is becoming easier and cheaper than ever.

True engineering, however, still lies in understanding the system, asking the right questions, and paying attention to the details that ultimately determine whether a solution succeeds or fails.

If you'd like to follow the project's progress or contribute, you can find Gunam on GitHub:

GitHub: https://github.com/IAmInYourKernel/gunam

While working on kiosk software at Zuchiz, I realized that many production issues cannot be solved from the application layer alone.

No matter how well an application is designed, its reliability ultimately depends on the environment in which it runs. In production, there are several factors outside the application's control that can silently degrade the user experience or even break the entire workflow.

Some common examples include:

• Unstable or intermittent internet connectivity

• Weak or fluctuating power supply

• Hardware failures such as storage corruption, memory issues, or peripheral malfunctions

• Device-specific operating system issues

• Unexpected application crashes or system restarts

These problems often surface as application failures, even though the root cause lies much deeper in the system.

Another challenge becomes evident as deployments scale: software updates.

Managing hundreds or thousands of on-premise devices is far more difficult than updating software running in the cloud. Although Over-the-Air (OTA) updates exist, most existing solutions are designed for embedded Linux environments. There are comparatively fewer solutions that provide the same level of flexibility for Android-based kiosks, Android TV boxes, Windows devices, or heterogeneous deployments.

As the number of deployed devices grows, monitoring device health and delivering reliable software updates become operational challenges rather than just engineering tasks. The complexity increases, costs rise, and scaling the business becomes significantly harder.

The Solution I Wanted to Build

Earlier this year, I started learning Rust with a different goal in mind. I wanted to migrate an ERP application I had built in Node.js to Rust so that it could deliver better performance while running on cost-effective production servers.

As I learned more about Rust, I realized that performance wasn't its biggest advantage. What impressed me most was its approach to memory safety, predictable resource management, and its ability to build reliable system level software.

That completely changed the way I thought about solving production problems.

The challenges I had experienced with on-premise devices monitoring hardware health, collecting telemetry, delivering reliable software updates, and continuing to operate even when connectivity was unreliable could not be solved entirely from the application layer. They required software that could interact closely with the operating system while remaining stable over long periods of time.

Rust felt like the right foundation for building that kind of software.

That realization led to the creation of Gunam.

Gunam is an open-source Rust agent designed for managing fleets of on-premises devices. It focuses on three core capabilities:

• Reliable OTA software updates

• Telemetry and system health collection

• Offline first synchronization for unreliable network environments

The project is designed with reliability as a first-class goal. One of Gunam's design goals is a panic-safe FFI layer that prevents Rust panics from propagating into the host application, making it easier to integrate Gunam into existing software regardless of the language it was written in.

Gunam is currently Linux first, with planned support for Android and Windows in future releases.

Gunam is still in its early stages, and I'm currently working toward the first public release.

The initial version focuses on building a solid foundation with:

• Operating system detection

• CPU, memory, battery, internet, and uptime monitoring

• Image-based OTA updates with A/B partitioning and delta update support

• A networking layer for telemetry, alerts, and remote session APIs

• A panic-safe FFI layer for reliable integration with existing applications

This is only the beginning. In future articles, I'll share the architecture, design decisions, implementation details, and the lessons I learned while building Gunam in public.

If you'd like to follow the project's progress or contribute, you can find Gunam on GitHub:

GitHub: https://github.com/IAmInYourKernel/gunam