Forem: Igor Giamoniano

How to Remove Orphan Linux Boot Entries from Windows 11 UEFI

Igor Giamoniano — Tue, 14 Apr 2026 14:06:05 +0000

Level: Intermediate

Estimated Time: 15–20 minutes

Operating System: Windows 11 (UEFI systems)

Summary

After replacing a Linux installation (such as Pop!_OS, Ubuntu, or Arch Linux) with Windows 11, old boot entries may remain visible in UEFI firmware.

This happens because UEFI boot configuration is stored in:

EFI System Partition (ESP)
UEFI NVRAM boot entries

Both must be cleaned.

⚠️ Before you start: Backup your data. Modifying the EFI partition or NVRAM entries can make your system unbootable if done incorrectly.

Technical Background

EFI System Partition (ESP)

The EFI System Partition (ESP) is a FAT32-formatted partition that stores the bootloaders for all installed operating systems. On Windows systems, it typically ranges from 100–500 MB in size and is labeled as "System".

Typical structure:

EFI/
├── Microsoft/
├── Boot/
├── pop_os/
├── systemd/
├── ubuntu/
└── linux/

⚠️ Do NOT remove:

Microsoft/

Boot/

NVRAM Boot Entries

UEFI firmware stores boot entries in non-volatile memory.

Each entry contains:

GUID identifier
Description
Path to EFI loader
Device reference

Removing EFI files does not remove NVRAM entries.

Step 1 — Mount EFI Partition

Open Command Prompt as Administrator.

diskpart

list disk
select disk 0
list partition

⚠️ Replace 0 with your system disk number.

select partition 1
assign letter=Z
exit

⚠️ Replace 1 with the EFI partition (~100–500 MB, Type: System)

Step 2 — Remove Linux Bootloader Files

Z:
cd \EFI
dir

Remove Linux folders:

rmdir /s /q systemd
rmdir /s /q pop_os

Parameters:

/s → removes directories recursively
/q → quiet mode (no confirmation)

Permission Errors

takeown /f systemd /r /d y

Parameters:

/f → target folder
/r → recursive
/d y → auto confirm

💡 On Portuguese Windows, use /d s instead of /d y.

icacls systemd /grant Administrators:F /t

rmdir /s /q systemd

Step 3 — Remove NVRAM Boot Entries

3.1 List firmware entries

bcdedit /enum firmware

Example output:

Firmware Application (101fffff)
-------------------------------
identifier              {29c75bf6-3303-11f1-b7f4-e7fe7d8485ec}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\systemd\systemd-bootx64.efi
description             Pop!_OS

Firmware Application (101fffff)
-------------------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager

3.2 Identify entries to remove

Remove entries that reference:

systemd
pop_os
ubuntu
linux

3.3 Delete orphan entry

bcdedit /delete {29c75bf6-3303-11f1-b7f4-e7fe7d8485ec} /f

Parameter:

/f → force deletion without confirmation

⚠️ NEVER delete:

{bootmgr}

{current}

Step 4 — Remove drive letter

diskpart
select disk 0
select partition 1
remove letter=Z
exit

Troubleshooting

Problem 1 — Access denied

takeown /f systemd /r /d y
icacls systemd /grant Administrators:F /t
rmdir /s /q systemd

Problem 2 — delete fails

Possible causes:

entry already removed
firmware protected entry
invalid reference

Solution:

reboot
remove EFI files first
run again

Problem 3 — entry still appears

Possible causes:

firmware cache
fallback recreated
BIOS bug

Solutions:

reboot twice
load BIOS defaults
update BIOS

Problem 4 — Windows does not boot

Method 1 — Startup Repair

Boot Windows installer USB
Repair your computer
Startup Repair

Method 2 — Recovery Command Prompt

bcdboot C:\Windows /s Z: /f UEFI

Commands Used

Command	Purpose	Documentation
diskpart	Disk and partition management	https://learn.microsoft.com/windows-server/administration/windows-commands/diskpart
bcdedit	Manage firmware boot entries	https://learn.microsoft.com/windows-hardware/drivers/devtest/bcdedit
takeown	Take ownership of files	https://learn.microsoft.com/windows-server/administration/windows-commands/takeown
icacls	Modify permissions	https://learn.microsoft.com/windows-server/administration/windows-commands/icacls
rmdir	Remove directories	https://learn.microsoft.com/windows-server/administration/windows-commands/rmdir
bcdboot	Rebuild Windows bootloader	https://learn.microsoft.com/windows-hardware/manufacture/desktop/bcdboot-command-line-options

Version Notes

Version	Date	Changes
1.0	April 2026	Initial procedure
1.1	April 2026	Added EFI explanation
1.2	April 2026	Added NVRAM cleanup
1.3	April 2026	Added troubleshooting
1.4	April 2026	Added command table
1.5	April 2026	Added recovery section
1.6	April 2026	Safety and locale improvements

✅ Quick Checklist (click to expand)

[ ] Backup completed
[ ] Disk/Partition numbers verified
[ ] Microsoft/ and Boot/ preserved
[ ] {bootmgr} and {current} not deleted
[ ] Drive letter removed

Tested Environment

Windows 11 24H2
UEFI firmware
GPT disk
Pop!_OS systemd-boot

Disclaimer

Backup before modifying EFI partition.
Verify disk and partition numbers carefully.

Diagnosing Multiple GPUs on Linux: How to Detect and Monitor Integrated and Dedicated GPUs

Igor Giamoniano — Sun, 15 Mar 2026 00:13:40 +0000

If you run Linux on a system with both an integrated GPU and a dedicated GPU, you may have noticed something strange: some monitoring tools only show one GPU.

This situation is common on:

laptops with hybrid graphics
desktops with iGPU + dedicated GPU
systems using different driver stacks

For example, a monitoring tool like btop might show your AMD integrated GPU but completely ignore your NVIDIA card.

In this article we will walk through how to:

detect all GPUs installed in your system
verify that the correct drivers are loaded
identify which GPU is rendering your desktop
monitor usage for each GPU
automate the entire diagnostic process with a small script

Why This Happens

Linux systems with multiple GPUs may behave differently depending on:

installed drivers (open source vs proprietary)
kernel configuration
which GPU is configured as the primary renderer
monitoring tool capabilities

Example setup used in this article:

AMD Vega (integrated) — Ryzen 5 5600G
NVIDIA GTX 1050 Ti (dedicated)

In this configuration, btop showed only the AMD GPU while the NVIDIA card remained invisible in the default monitoring view.

Step 1 — Check if Both GPUs Are Detected

1.1 List GPUs via PCI

Run:

lspci | grep -i vga

Example output:

01:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti]
09:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series]

If two entries appear, your hardware is being detected correctly.

1.2 Check Loaded Drivers

Run:

lsmod | grep -E 'nvidia|amdgpu|radeon'

Typical modules:

GPU	Kernel Module
NVIDIA	`nvidia`, `nvidia_drm`, `nvidia_modeset`
AMD (modern)	`amdgpu`
AMD (legacy)	`radeon`

If the modules appear, the drivers are loaded by the kernel.

1.3 Check Which GPU Is Rendering Your Desktop

Use:

glxinfo | grep "OpenGL renderer"

Example output:

OpenGL renderer string: NVIDIA GeForce GTX 1050 Ti

If glxinfo is missing, install it.

Ubuntu / Debian:

sudo apt install mesa-utils

Arch Linux:

sudo pacman -S mesa-utils

This command reveals which GPU is rendering the graphical session.

In hybrid setups, the integrated GPU often renders the desktop while the dedicated GPU activates only for demanding workloads.

Step 2 — Monitoring Each GPU

2.1 Integrated GPU (AMD / Intel) — Using btop

Launch:

btop

Inside btop:

press g to toggle GPU views
press 5 / 6 / 7 for specific GPU panels
configure via F2 → Options → CPU box → Show GPU info

2.2 NVIDIA Dedicated GPU — Using nvidia-smi

For NVIDIA GPUs the official tool is the most reliable:

watch -n 1 nvidia-smi

This updates every second and displays:

GPU utilization
memory usage
running processes

Structured output:

nvidia-smi --query-gpu=name,memory.used,memory.total,utilization.gpu --format=csv -l 1

Step 3 — Automating GPU Diagnostics

Create a script called:

check_gpus.sh

Script:

#!/bin/bash

echo "=== GPUs Detected ==="
lspci | grep -E "VGA|3D"

echo -e "\n=== Loaded Drivers ==="
lsmod | grep -E "nvidia|amdgpu|radeon"

echo -e "\n=== NVIDIA GPU ==="
nvidia-smi --query-gpu=name,memory.total --format=csv 2>/dev/null || echo "NVIDIA not detected"

echo -e "\n=== Rendering GPU ==="
glxinfo | grep "OpenGL renderer" 2>/dev/null || echo "glxinfo not available"

echo -e "\n=== DRM Devices ==="
ls /sys/class/drm | grep card

Make executable:

chmod +x check_gpus.sh

Run:

./check_gpus.sh

This quickly shows:

detected GPUs
active drivers
rendering GPU
NVIDIA status
DRM device nodes

Recommended Tools Summary

GPU Type	Recommended Tool	Command
AMD / Intel (integrated)	`btop`	`btop`
NVIDIA (dedicated)	`nvidia-smi`	`watch -n 1 nvidia-smi`
Hardware detection	`lspci`	`lspci \| grep -i vga`
Rendering check	`glxinfo`	`glxinfo \| grep "OpenGL renderer"`

Conclusion

Working with multiple GPUs on Linux doesn't have to be confusing.

Using the commands shown above you can:

verify hardware detection
confirm driver loading
identify which GPU renders your desktop
monitor GPU usage in real time
automate diagnostics with a small script

Different GPU stacks require different tools, but combining a few commands provides full visibility into your graphics subsystem.

Additional Resources

btop documentation

https://github.com/aristocratos/btop

NVIDIA System Management Interface

https://developer.nvidia.com/nvidia-system-management-interface

Arch Linux Wiki — NVIDIA

https://wiki.archlinux.org/title/NVIDIA

Rescuing Legacy Hardware: Installing Linux on Early UEFI Systems (Debian 13 Case Study)

Igor Giamoniano — Sat, 31 Jan 2026 02:36:03 +0000

TL;DR

Modern Linux installers increasingly assume fully compliant UEFI firmware. On early-generation UEFI systems (circa 2011–2013), this assumption often breaks. This article documents a real-world case where Debian 13, installed in Legacy (MBR + GRUB i386-pc) mode, proved to be the most reliable solution.

Context: When a Simple Reinstall Fails

A Lenovo QiTian M435E (2012), equipped with a Kingston SV300S3 SSD and early-generation UEFI firmware, suffered an OS corruption after an electrical incident. The expected fix — reinstalling Linux — turned into a multi-distro debugging session.

Several modern distributions completed installation successfully but failed to boot afterward, even when configuration steps appeared correct.

Early UEFI Is Not Modern UEFI

The QiTian M435E provides firmware options labeled "UEFI Only" and "Legacy Only". However, this system uses an early UEFI implementation common in pre-2014 corporate hardware.

Characteristics of this class of firmware include:

Partial or unstable EFI variable (NVRAM) support
Inconsistent handling of GPT + EFI System Partitions
Unreliable interaction with modern GRUB EFI targets

As a result, systems may technically support UEFI while failing to boot reliably with contemporary Linux installers.

Why Several Modern Distros Failed

Ubuntu 24.04 / Linux Mint 22 / Zorin OS 17

These distributions:

Default to GPT partitioning
Assume a functional EFI System Partition
Install GRUB primarily in x86_64-efi mode

On early UEFI systems, this results in:

Missing or ignored boot entries
Firmware failing to locate EFI binaries
Systems reporting "No operating system found"

This behavior is not a bug but a consequence of architectural assumptions.

Why Debian 13 Worked

Debian 13 (Trixie) maintains robust support for legacy boot paths:

Honors MBR (msdos) partition tables when disks are clean
Installs GRUB using the i386-pc target when booted in Legacy mode
Does not require an EFI System Partition in BIOS/Legacy setups
Explicitly asks where GRUB should be installed

This results in a predictable, firmware-compatible boot chain.

Tested Installation Procedure (Legacy Mode)

Prerequisites

debian-13.x-amd64-netinst.iso
Firmware set to Legacy Only
Secure Boot and UEFI disabled

Disk Preparation

Ensure the disk uses MBR, not GPT:

sudo wipefs -a /dev/sda
sudo parted /dev/sda mklabel msdos

Installation

Choose: Guided – use entire disk
Filesystem: ext4
Avoid separate /boot partitions
Confirm GRUB installation to /dev/sda (not /dev/sda1)

Internally, Debian executes:

grub-install --target=i386-pc --boot-directory=/boot /dev/sda

Key Technical Takeaway

Component	Debian 13	Modern Ubuntu-based Distros
Partition table	Respects MBR	Defaults to GPT
GRUB target	i386-pc	x86_64-efi
EFI requirement	Not required	Assumed
Firmware tolerance	High	Low on early UEFI

Conclusion

Legacy and early-UEFI systems are not obsolete — they are underserved. Debian 13 remains one of the few mainstream distributions that still treats non-modern firmware as a first-class scenario rather than an edge case.

For environments with pre-2014 hardware, predictability often matters more than novelty.

References

🛡️ Securing Clawdbot (Moltbot): Essential Hardening for AI Agents with System Access

Igor Giamoniano — Wed, 28 Jan 2026 19:08:52 +0000

⚠️ Why Security Is Non-Negotiable with Agentic AI

Unlike chatbots, Clawdbot (now Moltbot) runs locally with direct system access.

That means it can:

Read and write files
Execute shell commands
Control browsers and sessions
Access credentials and tokens

This turns it into an AI-powered automation layer over your entire machine — which is powerful, but also extremely risky if misconfigured.

Think of it less like “installing an app” and more like:

Adding a new sysadmin to your system that never sleeps.

This article covers practical steps to reduce attack surface and prevent full system compromise.

✅ 1. Use a Separate Machine or Environment

Never install Clawdbot on your main personal computer.

Recommended options:

Cloud VPS (AWS, Hetzner, DigitalOcean)
Old laptop used only for automation
Mini PC / home lab server

Why this matters:

If the agent is compromised, your personal data, banking info and passwords stay isolated.

Treat it like:

Work phone vs personal phone

Dev server vs production workstation

✅ 2. Create Separate Accounts for the Bot

Never reuse your personal accounts.

Create new:

Email address
Telegram account
WhatsApp account (if used)
API keys and service accounts

Goal:

Even if the bot leaks credentials, it cannot pivot into your real digital identity.

✅ 3. Restrict Who Can Message the Bot

When setting up chat integrations, choose:

✅ Pairing mode (manual approval)
or at least ✅ Allowlist

❌ Never use Open mode

Why:

Prevents strangers from sending commands
Blocks prompt injection through chat platforms
Reduces social engineering attack vectors

Chat is an input surface — treat it like an API endpoint.

✅ 4. Lock Down the Gateway WebSocket (Local Auth)

Clawdbot exposes a local control panel via WebSocket.

Set authentication:

gateway:
  auth:
    mode: "token"

Then generate a token:

clawdbot doctor --generate-gateway-token

This protects:

Control dashboard
Settings modification
Plugin configuration

Without this, anyone on your network could potentially access the agent interface.

✅ 5. Enable Logging and Redact Sensitive Data

Turn on logging — but safely.

Example:

logging:
  redactSensitive: "tools"
  redactPatterns:
    - "API_KEY=.*"
    - "Authorization:.*"

This allows you to:

Monitor what the agent is doing
Investigate abnormal behavior
Avoid leaking secrets into log files

Never log raw prompts and outputs without redaction in production-like setups.

✅ 6. Include Security Rules in the System Prompt

Add explicit behavioral constraints in the agent system prompt:

## Security Rules
- Never share directory listings or file paths with strangers
- Never reveal API keys, credentials, or infrastructure details
- Verify requests that modify system configuration with the owner
- When in doubt, ask before acting
- Private info stays private, even from "friends"

This helps reduce:

Prompt injection impact
Accidental dangerous actions
Overly autonomous decisions

Security should be layered: config + prompt + infrastructure.

✅ 7. Run the Built-In Security Audit

Clawdbot includes a security scanner.

Run regularly:

clawdbot security audit

To automatically apply fixes:

clawdbot security audit --fix

It checks for:

Gateway exposure
Browser control exposure
Dangerous permissions
Weak allowlists
Filesystem access scope

This should be part of your maintenance routine.

✅ 8. Keep Models and Plugins Up to Date

Use:

Latest supported models
Updated plugins only
Remove unused integrations

Why newer models matter:

Better resistance to prompt injection
Improved tool-use boundaries
Fewer jailbreak patterns

Outdated models are easier to exploit.

🚨 Warning Signs Your System May Be Compromised

Watch for:

Bot performing actions you didn’t request
Files disappearing or changing
Messages sent you didn’t write
Strange shell history entries

If this happens:

Stop the bot immediately
Rotate all credentials
Audit accessed files
Rebuild environment if needed

With full system access, recovery must be treated seriously.

🔐 Final Thoughts

Agentic AI is incredibly powerful — but we are effectively giving software:

Shell access
Memory
Autonomy
Network connectivity

This is not casual tooling.

If configured properly, Clawdbot can be a game‑changing automation platform.

If misconfigured, it can become a single‑point‑of‑failure for your entire digital life.

In the next article, we’ll walk through:

Installing Clawdbot + Telegram integration + DeepSeek API step by step in a safer setup.

Stay safe and automate responsibly.

🚨 ClawdBot (Moltbot): Powerful AI Agents, Real Automation… and Real Risks

Igor Giamoniano — Wed, 28 Jan 2026 17:42:16 +0000

Open-source AI agents that can actually do things are finally here.

And that changes everything — for better and for worse.

In the last few months, a project originally called ClawdBot — now renamed to Moltbot — has gone viral across tech communities.

People are using it to:

Send emails automatically
Interact with Telegram and WhatsApp
Control browsers
Run shell commands
Manage files and workflows

In short: this is not just another chatbot.

This is an autonomous AI agent with full system access.

And that is both incredible… and dangerous.

Let’s break down why.

What is ClawdBot / Moltbot?

ClawdBot (now Moltbot) is an open‑source AI agent framework designed to:

Run locally on your machine or server
Maintain long‑term context
Execute real actions instead of just generating text
Integrate with messaging apps like Telegram and WhatsApp
Control browsers, files, and system commands

The project’s tagline is literally:

“The AI that actually does things.”

And it delivers on that promise.

Unlike traditional chatbots, Moltbot can:

Read and write files
Execute shell commands
Open websites
Send messages on your behalf
Chain multiple actions together autonomously

This makes it extremely powerful for automation, productivity, and experimentation with agentic AI.

Why Did It Go Viral?

Most AI tools today are still limited by:

API boundaries
Sandbox environments
Strict permission models

Moltbot removes many of those barriers by design.

It behaves more like:

a digital assistant living inside your computer

than a chatbot living inside a browser tab.

For developers and power users, that is incredibly appealing.

You can build agents that:

Monitor systems
Interact with services
Perform multi‑step tasks
React to real‑world events

It feels like the future of AI agents — and in many ways, it is.

But Here’s the Problem: Full System Access

Moltbot doesn’t just simulate actions.

It can have access to:

Your filesystem
Your terminal
Your browser with saved sessions
Your environment variables
Your credentials
Your personal messages

Security researchers and engineers have been very clear about this:

Running an AI agent with shell access on your machine is… spicy.

And that’s not fear‑mongering — it’s basic threat modeling.

If something goes wrong, the blast radius is your entire system.

What Could Go Wrong?

Here are some realistic risk scenarios:

🔓 Prompt Injection

If your agent receives malicious instructions through:

Messages
Websites
Files
APIs

It may execute commands you never explicitly approved.

🗝️ Credential Exposure

If the agent can read:

Config files
Environment variables
Browser sessions

An exploit could leak:

API keys
Tokens
Passwords

📂 File System Damage

Misconfigured agents could:

Delete files
Modify configs
Corrupt projects

Not out of malice — but due to flawed instructions or bugs.

🌐 Network Abuse

If connected to external services, compromised agents could:

Send spam
Participate in attacks
Expose your IP or infrastructure

This turns your machine into part of someone else’s problem.

Experts Are Not Saying “Don’t Use It”

Interestingly, most security professionals are not saying:

“Avoid this project.”

They are saying:

“Use it responsibly, with strong isolation and safeguards.”

The technology itself is impressive.

The danger comes from:

Running it on personal machines
Giving it broad permissions
Skipping security configuration

Which, unfortunately, many people do when testing new tools.

Name Change: ClawdBot → Moltbot

You may see the project referenced under two names.

The creator recently renamed it to Moltbot due to trademark concerns after contact from Anthropic.

Same project.

Same mission.

Same capabilities.

Just a new shell — like a lobster molting.

So… Should You Use It?

If you are a developer, researcher, or power user:

Yes, it’s an exciting platform to explore agentic workflows.

But you should treat it like:

running experimental infrastructure software, not a casual desktop app.

It deserves:

Dedicated environments
Isolated machines or VMs
Careful configuration

Which brings us to the most important part.

Next Step: How to Use Moltbot Safely

In this article we focused on what it is and why it’s risky.

In the next post, we’ll go into practical security configuration, including:

Using separate machines or cloud instances
Locking down gateway authentication
Enabling logging with sensitive data redaction
Running built‑in security audits
Hardening system prompts and permissions

If you plan to test this tool, those steps are not optional.

They are the difference between:

experimenting safely

and

exposing your entire digital life to unnecessary risk.

Final Thoughts

AI agents that can actually act on the world are not science fiction anymore.

They are here.

They are powerful.

And they demand a much higher level of operational security than chatbots ever did.

The future of AI is not just about smarter models —

it’s about responsible deployment.

And that responsibility now sits with developers too.

How to Build The Rust Programming Language Book Locally on Linux

Igor Giamoniano — Sat, 17 Jan 2026 14:18:04 +0000

Introduction

If you prefer learning from books and documentation instead of videos, Rust offers one of the best learning resources available:

The Rust Programming Language, also known as The Rust Book.

The book is open source, maintained by the community, and available in several languages — including Portuguese (pt-BR) and other community translations.

In this tutorial, you will learn how to:

Install Rust on your system
Install mdbook, the tool used to build the book
Build the book locally on your machine
Open the full documentation in your browser, offline

As a bonus, you will already have part of your Rust development environment set up.

This guide focuses on Linux, but the process is very similar on other operating systems.

Why Build the Book Locally?

Reading the book online is perfectly fine, but building it locally has some advantages:

Offline access
Faster navigation between chapters
Easy access to the source files
Possibility to contribute with fixes and improvements

If you enjoy learning by exploring real project structures, this is a great way to start.

Official online version of the book:

https://doc.rust-lang.org/stable/book/

Step 1: Installing Rust

To build the book, we first need to install Rust and its package manager, Cargo.

The official and recommended way to install Rust is using rustup.

Run the following command in your terminal:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y

If everything goes well, you should see a message similar to:

Rust is installed now. Great!
To get started you may need to restart your current shell.
This would reload your PATH environment variable to include
Cargo's bin directory ($HOME/.cargo/bin).

Reload Your Environment Variables

To make sure Cargo is available in your current terminal session, run:

. "$HOME/.cargo/env"

Now verify the installation:

rustc --version

Expected output example:

rustc 1.84.1 (e71f9a9a9 2025-01-27)

Step 2: Installing mdBook

mdbook is the tool used to build and serve the Rust Book.

Install it using Cargo:

cargo install mdbook

You can confirm installation with:

mdbook --version

Official mdBook documentation:

https://rust-lang.github.io/mdBook/

Step 3: Cloning the Book Repository

Now clone the book repository.

For the Brazilian Portuguese translation:

git clone https://github.com/rust-br/rust-book-pt-br.git
cd rust-book-pt-br

For the original English version:

git clone https://github.com/rust-lang/book.git
cd book

Choose the version that best fits your learning needs.

Step 4: Building the Book

Inside the project directory, run:

mdbook build

After the build finishes, the generated site will be inside the book/ directory.

Open it in your browser:

xdg-open book/index.html

Or:

firefox book/index.html

If your terminal cannot open the browser, you can also navigate manually using your file manager and open:

book/index.html

Step 5: (Optional) Running a Local Server

Instead of opening static files, you can also run a local server:

mdbook serve

Then open:

http://localhost:3000

This is useful if you want live reload while editing files or exploring the structure.

Conclusion

Building the Rust Book locally may look unnecessary at first, but it helps you:

Install Rust properly
Learn how Cargo works
Understand how Rust documentation is structured
Get closer to the open-source ecosystem

Learning a language becomes much easier when you actively explore its tools and community.

If you're starting your Rust journey and prefer documentation over videos, this is an excellent first step.

Happy coding 🦀

Understanding Web3 and Solana: Foundations Before Your First Smart Contract

Igor Giamoniano — Fri, 16 Jan 2026 04:35:55 +0000

Introduction

In recent years, Web3 and blockchain have moved far beyond investment
hype and have become part of real-world software development.\
However, many tutorials jump straight into code without explaining the
mental model required to build applications correctly on a
blockchain.

Before writing any Rust code or using frameworks like Anchor, it is
essential to understand:

What Web3 really means for developers\
How blockchains work under the hood\
What smart contracts are and how Solana treats this concept\
Why Solana's architecture is fundamentally different

This article is fully conceptual.\
In the next part, we will move into practice with environment setup and
your first Solana program.

What Web3 Really Means for Developers

For developers, Web3 is not about speculation or tokens.\
It is about who controls the state of the application.

In traditional applications:

The backend controls the database\
The company defines the rules\
Users must trust the server

In Web3:

Critical application state lives on a public blockchain\
Rules are enforced by on-chain code\
Anyone can verify how the system behaves

User interfaces, APIs, and indexers still exist, but they become
support layers, not the source of truth.

This architectural shift is what enables truly decentralized
applications.

Blockchain as a Distributed State Machine

A technical way to view a blockchain is as a global, distributed state
machine.

Each transaction:

Reads the current state\
Executes deterministic logic\
Produces a new state validated by the network

All validators execute the same logic and reach the same result,
ensuring the ledger remains immutable and verifiable.

Unlike traditional databases, you cannot:

Freely update records\
Delete historical data\
Manually fix inconsistencies

Every change must happen through a valid, signed, and verified
transaction.

Smart Contracts vs Programs on Solana

On many blockchains, such as Ethereum, smart contracts:

Contain code\
Store their own state

Solana uses a different model.

Smart contracts are called programs, and they:

Contain only logic\
Do not store state internally

All persistent data lives in separate structures called Accounts.

Programs receive these accounts as inputs, validate them, and modify
their data when allowed.

This separation between:

Code (programs)\
Data (accounts)

is one of Solana's most important architectural differences and strongly
affects application design.

Why Solana Is Architecturally Different

Solana was designed around parallel transaction execution.

To make this possible, the network must know in advance:

Which accounts a transaction will read\
Which accounts a transaction will write

If two transactions do not touch the same accounts, they can run at the
same time.

This model:

Greatly increases throughput\
Requires developers to explicitly declare all data dependencies

That is why, when writing Solana programs, every account involved in an
instruction must be listed explicitly.

Nothing is accessed implicitly.

The Role of Accounts in Application Design

Accounts are the real database of Solana.

They can store:

Custom data structures\
Token balances\
NFT metadata\
Protocol configuration

Each account has:

An address\
An owner (usually a program)\
Persistent binary data

A program can only modify accounts that it owns.

This creates a very explicit and predictable security model.

For developers, this means application design often starts with
account design, not with function logic.

What Anchor Is and Why It Matters

Developing directly on Solana's runtime in Rust is possible, but
extremely verbose.

Anchor is a framework that:

Automates data serialization\
Validates accounts automatically\
Reduces repetitive boilerplate\
Integrates TypeScript testing

With Anchor, developers describe:

Which accounts an instruction expects\
Which constraints must be enforced

And the framework generates most of the validation logic.

This allows developers to focus on protocol logic instead of low-level
runtime details.

For this reason, most professional Solana projects today use Anchor.

What You Should Understand Before Writing Code

Before moving into hands-on development, it is important to understand
that:

Programs do not store state\
Accounts are the actual storage layer\
Transactions must declare all accounts they use\
Execution is deterministic and globally validated\
Compute costs always matter

These principles explain why Solana development feels different from
both Web2 systems and EVM-based blockchains.

With the correct mental model, the code will stop feeling strange and
start making sense.

Next Step: Hands-On Development

In the next article of this series, we will move into practice:

Setting up the full development environment\
Creating a local development wallet\
Initializing an Anchor project\
Implementing a simple counter program using a PDA\
Testing everything locally with solana-test-validator

The goal is to move directly from theory into a real professional
development workflow.

BTOP++: The Resource Monitor I Didn’t Know I Needed

Igor Giamoniano — Sat, 03 Jan 2026 03:07:00 +0000

Today is January 1st, 2026. The holidays are over, keyboards are warming up again, and it’s time to get back to building things.

There’s been a lot of talk about **2026 being “the year of Linux.” **Steam even kicked off the year with a banner suggesting exactly that. Will it actually be? I honestly don’t know.

What I do know is that 2025 was the year of Linux for me. After four years working as a developer and using Linux only sporadically, things finally clicked at the end of last year — and since then, the penguin has completely taken over my workflow.

My wife can confirm it.
Even with the Brazilian summer heat, we don’t use Windows at home.😄

With that in mind, this post is both a small New Year wish — and a quick, practical introduction to a resource monitor I genuinely didn’t know I needed: BTOP++.

BTOP++ vs HTOP

First of all, this is not an attack on HTOP.

On the contrary: HTOP is an amazing tool, created by my fellow countryman Hisham Muhammad, written in C, and known for being extremely efficient. It earned its place in the Linux community and even in hacker pop culture for a reason.

Many of the features I’ll mention for BTOP++ already exist in HTOP.

So the real question is:

Why consider BTOP++?

BTOP++ is the natural evolution of the HTOP idea.

It is inspired by HTOP but written in C++, which allows:

More information displayed at once in the same terminal
Integrated graphs for CPU, memory, disk, and network
A more modern and polished look
Extra visual context without a noticeable performance hit

Those visuals make a real difference when you’re trying to understand resource usage patterns.

Should You Switch?

As always in tech, there’s no silver bullet.

HTOP is still:

Minimal
Fast
Extremely reliable
Perfect for SSH sessions and servers

BTOP++, on the other hand, is:

More complete
Visually rich
Modern
Ideal for desktops and workstations

A simple summary:

HTOP → minimal, fast, reliable, great for servers
BTOP++ → complete, beautiful, modern, great for desktop/workstation

Both tools can easily coexist.

Installation

Big Linux / Arch / Manjaro

sudo pacman -Syu   # update the system
sudo pacman -S btop

After installation, just run:

btop

Ubuntu 22.10 or newer

sudo apt update
sudo apt install btop

Ubuntu 22.04 LTS or older

sudo snap install btop

Useful Shortcuts

Inside BTOP++:

ESC or M → open the menu
↑ / ↓ → navigate processes
F → filter processes by name
K → kill the selected process

You can find all available shortcuts under Help inside the menu.

That’s it.

Long live Linux — and happy hacking 🐧

Why Does the System Clock Break on Windows + Linux Dual Boot?

Igor Giamoniano — Mon, 29 Dec 2025 14:16:20 +0000

Introduction

Anyone running dual boot with Windows and Linux has likely encountered this behavior:

Linux shows the correct time. You reboot into Windows… and the system clock is suddenly several hours ahead.

This happens across many distributions — Ubuntu, Fedora, Linux Mint, Big Linux, and others — and it is not a bug.

It is the result of fundamentally different architectural decisions about how operating systems interpret time.

In this article, you’ll learn:

What the RTC (Real-Time Clock) is
How Linux and Windows interpret system time differently
Why the issue happens
The technically correct solution

What Is the RTC (Real-Time Clock)?

Every computer has a Real-Time Clock, also known as the hardware clock.

It:

Is powered by the motherboard battery
Keeps time while the system is turned off
Lives in the firmware (BIOS/UEFI)
Provides the initial system time during boot

The key detail

The RTC does not store timezone information.

It only stores a raw date and time value.

👉 The operating system decides how that value is interpreted.

This is where the conflict begins.

How Linux Handles Time and Timezones

Linux and other Unix-like systems follow a long-established convention:

The RTC is treated as UTC
Timezone conversion happens in software

At boot time:

Linux reads the RTC as UTC
Applies the configured timezone offset
Displays the correct local time

When writing time back to the hardware clock, Linux keeps it in UTC.

This approach is technically robust and ideal for:

Multi-boot systems
NTP synchronization
Timezone changes
Predictable behavior

How Windows Handles System Time

Windows follows a different model.

By default, Windows assumes the RTC is set to local time.

The value read from the hardware clock is displayed directly, without applying a timezone conversion.

This design decision is historical and works well for single-OS systems, but it conflicts with Unix-like conventions.

Why the Clock Is Wrong in Dual Boot

Example for a system configured to UTC−3:

Local time: 15:00
UTC time: 18:00
Linux writes 18:00 (UTC) to the RTC
Windows reads 18:00 as local time

Result:

👉 The system clock appears 3 hours ahead in Windows.

This is not a synchronization issue — it is a clash between two different time models.

Recommended Fix: Configure Windows to Use UTC

From a technical perspective, the cleanest solution is to align Windows with the Linux model by making it interpret the RTC as UTC.

Steps

Open Registry Editor (regedit) as administrator
Navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

Create a DWORD (32-bit) value named:

RealTimeIsUniversal

Set its value to:

Reboot the system

After this change, Windows will correctly apply the timezone offset and the issue will be resolved permanently.

Alternative Fix: Force Linux to Use Local Time (Not Recommended)

It is also possible to force Linux to treat the RTC as local time:

timedatectl set-local-rtc 1 --adjust-system-clock

⚠️ This approach is not recommended.

It:

Breaks Unix-like conventions
Can cause NTP synchronization issues
Creates problems when changing timezones
Is explicitly discouraged by systemd documentation

This should only be used as a last-resort workaround.

Conclusion

The dual boot clock issue is not a bug — it’s the result of two different architectural approaches.

Linux treats the RTC as UTC
Windows assumes the RTC is local time

Understanding this distinction allows you to fix the problem once and for all.

Configuring Windows to use UTC is the most predictable and technically sound solution.

References

Microsoft — Windows Time Service

https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-top
systemd — timedatectl

https://www.freedesktop.org/software/systemd/man/latest/timedatectl.html
Arch Linux Wiki — System Time

https://wiki.archlinux.org/title/System_time
Ubuntu Documentation — Time and Date

https://help.ubuntu.com/stable/ubuntu-help/clock-set.html.en
Stack Overflow discussions on RTC and dual boot

https://stackoverflow.com/questions/73778596/windows-shows-wrong-time-after-dualboot

Merry Christmas… in Your Linux Terminal 🎄

Igor Giamoniano — Thu, 25 Dec 2025 20:59:36 +0000

And a Gentle Introduction to the Python CLI Ecosystem

Introduction

Today is Christmas — and if you’re reading this, I hope you’re doing well.

After a long year, our minds often try to create a false sense of urgency. Sometimes, the best thing we can do is pause, breathe, and say:
“Not now.”

With that in mind, this article brings a simple, fun, and educational tutorial, perfect for the holiday season.

The goal is straightforward:
👉 run a Christmas tree animation directly in your Linux terminal.

Yes — Linux developers would rather write 100+ lines of code than decorate a real tree.
And we deeply respect that.

What Are We Building?

We’ll run a Python-based CLI called christmastree, using a tool called pipx.

Along the way, you’ll learn:

What pipx is and why it matters
How to run Python CLI tools safely and in isolation
How to run christmastree on:
- most Linux distributions
- Big Linux / Manjaro (alternative setup)

What Is `pipx`?

pipx is a tool designed to install and run Python applications in isolated environments, without affecting:

the system Python
other projects
existing virtual environments

Each application gets its own virtual environment, but remains accessible globally through your PATH.

Examples of CLI Tools Installed with `pipx`

Popular examples include:

black — code formatter
poetry — dependency manager
httpie — terminal HTTP client
christmastree — your animated Christmas tree 🎄

Installation (Official Method — Works on Most Distros)

Step 1: Install `pipx`

pip install pipx
pipx ensurepath

You may need to open a new terminal afterward.

Step 2: Clone the official repository

git clone https://github.com/MEHighKing/christmastree.git
cd christmastree
pipx install .

Step 3: Run it 🎄

christmastree

Alternative Setup — Big Linux (Manjaro)

Big Linux is a Brazilian distribution based on Manjaro, so the only difference is how pipx is installed.

Install `pipx` via pacman

sudo pacman -S python-pipx

Then follow the same steps:

git clone https://github.com/MEHighKing/christmastree.git
cd christmastree
pipx install .

Common Issue: Terminal Size

If you see this error:

Please enlarge your terminal to at least 100x40 (current: 85x34).
[exit=1]

Just resize your terminal window.

Check current size with:

tput cols; tput lines

Once it reaches 100x40 or more, run:

christmastree

Important Note ⚠️

Some tutorials suggest running:

curl -L https://raw.githubusercontent.com/MEHighKing/christmastree/master/christmastree.sh | bash

This does not work.
There is no shell script in the repository. The correct approach is using pipx.

Conclusion

I hope everything ran smoothly 🎄

If you enjoyed it, consider visiting the official repository and leaving a ⭐ — those developers are powered by coffee and code ☕🐧

🔗 Official repository:
https://github.com/MEHighKing/christmastree

Merry Christmas — and long live Linux! 🐧 🖖

Web Privacy Is Not Incognito Mode

Igor Giamoniano — Mon, 22 Dec 2025 05:48:40 +0000

Introduction

For many users, web privacy still means opening an incognito window or installing an ad blocker.

In reality, that only addresses a small part of the problem.

Real privacy starts with browser architecture, design decisions, and how much the browser communicates with third parties, even when you’re not actively browsing.

In this article, I analyze five browsers that treat privacy as a technical requirement, not an optional feature.

Privacy ≠ Incognito Mode

Incognito mode:

Does not prevent fingerprinting
Does not block advanced trackers
Does not isolate the browser completely
Does not stop background communication

It only prevents local storage of history and cookies.

In other words, your activity can still be observed externally.

Browser Architecture and Threat Models

Before choosing a privacy-focused browser, you need to understand your threat model:

Do you want to reduce commercial tracking?
Avoid fingerprinting?
Minimize communication with big tech companies?
Achieve strong anonymity?

Each browser below solves a different problem.

Mullvad Browser — Privacy by Default

Developed by Mullvad in partnership with the Tor Project, Mullvad Browser is built on Firefox/Tor Browser.

Key characteristics

Zero telemetry
Strong fingerprinting resistance
Aggressive privacy defaults
No accounts or sync

Best use case: users who want maximum privacy with zero configuration.

LibreWolf — Full Control over Firefox

LibreWolf is a community-driven Firefox fork focused on control and transparency.

Key characteristics

Telemetry removed
Enhanced tracking protection
Full access to about:config
Gecko engine

Best use case: advanced users and developers who want privacy plus deep customization.

Ungoogled Chromium — Chromium Without Google

Ungoogled Chromium removes Google integrations from the Chromium codebase.

Key characteristics

No automatic calls to Google servers
No account-based sync
Very close to upstream Chromium

Important limitations

Privacy here comes from removing Google, not from active protection.

Manual tuning and extensions are still recommended.

Tor Browser — A Different Browsing Model

Tor Browser fundamentally changes the browsing paradigm.

Key characteristics

Onion routing
Session isolation
Aggressive fingerprinting resistance

Trade-offs

Reduced performance
Broken or limited websites
Less convenience

Best use case: journalists, activists, sensitive research, and strong anonymity needs.

Zen Browser — Privacy with Modern UX

Zen Browser is a Firefox-based browser focused on:

Privacy
Usability
Clean, modern design

It avoids telemetry while keeping a smoother daily experience.

Best use case: users who want a balance between privacy and convenience.

FAQ

Is there a “best” browser for privacy?

No. There is only the browser that best fits your threat model.

Should I still use extensions?

In browsers like Tor or Mullvad, fewer extensions are usually better.

In others, extensions may still be helpful.

Does incognito mode help?

Only locally. It does not protect against external tracking.

Conclusion

Web privacy is not a toggle — it is the result of architectural choices, design decisions, and accepted trade-offs.

There is no perfect browser.

There is only the one that best matches your anonymity needs, compatibility requirements, and usability expectations.

Understanding these differences is the first step toward more conscious browsing.

References

Tor Project — https://www.torproject.org/
Mullvad Browser — https://mullvad.net/browser
LibreWolf — https://librewolf.net/
Ungoogled Chromium — https://github.com/Eloston/ungoogled-chromium
Zen Browser — https://zen-browser.app/

Acknowledgment

This article was inspired by a discussion originally shared on Instagram by ZeroDay and Hacker01Girl.

While the original post introduced the topic in a short-form format, this article expands the idea into a deeper technical analysis focused on browser architecture, threat models, and real-world trade-offs.

Original inspiration:
https://www.instagram.com/p/DSM_pd1jwFh/

Controle de Áudio Personalizado no Linux: Alternando entre Fone, Caixas e Áudio Duplo com um Único Comando

Igor Giamoniano — Sun, 07 Dec 2025 22:02:15 +0000

TL;DR: Criei um script chamado audioctl que, com um único comando,
me permite alternar entre fone (via HDMI), caixas de som (analógicas) ou
até reproduzir em ambos ao mesmo tempo. Tudo isso com pactl, um
pouco de Bash e o poder do Linux.

O que é o `pactl`?

O pactl (abreviação de PulseAudio Control) é uma ferramenta de linha
de comando usada para controlar servidores de áudio como PulseAudio
e, com compatibilidade total, o PipeWire --- o sucessor moderno do
PulseAudio, usado por padrão em distros como Fedora, Ubuntu 22.04+, Arch
e NixOS.

Com ele, você pode:

Listar dispositivos de áudio (sinks e sources)
Mudar o volume
Alternar entre saídas
Mover streams de áudio entre dispositivos
Carregar ou descarregar módulos (como o module-combine-sink)

Ele é o "canivete suíço" do áudio no terminal --- e a base de tudo o que
vamos construir neste tutorial.

O problema

Eu uso um setup simples, mas comum:

Meu fone de ouvido está conectado ao monitor (que por sua vez está ligado ao PC via HDMI).
Minhas caixas de som estão ligadas diretamente na saída de áudio analógica do computador.

Meu sogro precisava conseguir alterar entre caixa de som e fone de
ouvido, coisa que ele já conseguia na interface, porém ele também
precisava conseguir colocar nas duas ao mesmo tempo (por questões de
acessibilidade).

Então pensei:

"Se o Linux me dá total controle do sistema, por que não criar meu
próprio controlador de áudio?"

E foi exatamente isso que fiz. Neste post, vou te mostrar passo a
passo como construí essa ferramenta --- e como você pode adaptá-la
para o seu setup.

Pré-requisitos

Um sistema Linux moderno (Ubuntu, Fedora, Arch, NixOS, etc.).
PulseAudio ou PipeWire.
Terminal e um editor de texto.
Pelo menos duas saídas de áudio funcionais.

💡 Se você não sabe se tem PipeWire ou PulseAudio, rode:
pactl info | grep "Server Name"
Se aparecer "PipeWire" ou "PulseAudio", está tudo certo!

Passo 1: Entenda sua configuração de áudio

Antes de automatizar, precisamos saber quais dispositivos existem.

Liste seus sinks (saídas de áudio):

pactl list sinks short

Saída de exemplo:

52  alsa_output.pci-0000_01_00.1.hdmi-stereo     ...  RUNNING
57  alsa_output.pci-0000_09_00.6.analog-stereo   ...  SUSPENDED

RUNNING = está em uso\
SUSPENDED = inativo, mas disponível

Agora veja os cards:

pactl list cards

Procure pelo seu dispositivo analógico e confirme o perfil ativo
(como output:analog-stereo).

Passo 2: Controle básico de volume

O pactl permite controlar o volume do sink padrão usando:

@DEFAULT_SINK@

# Aumentar 5%
pactl set-sink-volume @DEFAULT_SINK@ +5%

# Diminuir 5%
pactl set-sink-volume @DEFAULT_SINK@ -5%

Passo 3: Alternar entre saídas de áudio

Para mudar o sink padrão:

pactl set-default-sink NOME_DO_SINK

Mover streams ativos:

pactl list short sink-inputs
pactl move-sink-input ID_DO_STREAM NOVO_SINK

Passo 4: Áudio em dois dispositivos ao mesmo tempo (modo "dual")

pactl load-module module-combine-sink     sink_name=combined_output     slaves=alsa_output.hdmi,alsa_output.analog     sink_properties=device.description="Dual_HDMI+Analog"

Passo 5: O script final --- `audioctl`

Código completo

https://gist.github.com/igorgbr/8031267dee77acf6d7d298ec72a37f94

Como instalar

chmod +x ~/projetos/audioctl
mkdir -p ~/bin
ln -sf ~/projetos/audioctl ~/bin/audioctl

Dicas extras

speaker-test -t wav -c 2

Conclusão

Com menos de 60 linhas de Bash, resolvi um problema real --- com
flexibilidade que nenhum app gráfico oferece.

✨ O controle está nas suas mãos --- e no terminal.

Código completo

https://gist.github.com/igorgbr/8031267dee77acf6d7d298ec72a37f94

Forem: Igor Giamoniano

How to Remove Orphan Linux Boot Entries from Windows 11 UEFI

Summary

Technical Background

EFI System Partition (ESP)

NVRAM Boot Entries

Step 1 — Mount EFI Partition

Step 2 — Remove Linux Bootloader Files

Permission Errors

Step 3 — Remove NVRAM Boot Entries

3.1 List firmware entries

3.2 Identify entries to remove

3.3 Delete orphan entry

Step 4 — Remove drive letter

Troubleshooting

Problem 1 — Access denied

Problem 2 — delete fails

Problem 3 — entry still appears

Problem 4 — Windows does not boot

Commands Used

Version Notes

Tested Environment

Disclaimer

Diagnosing Multiple GPUs on Linux: How to Detect and Monitor Integrated and Dedicated GPUs

Why This Happens

Step 1 — Check if Both GPUs Are Detected

1.1 List GPUs via PCI

1.2 Check Loaded Drivers

1.3 Check Which GPU Is Rendering Your Desktop

Step 2 — Monitoring Each GPU

2.1 Integrated GPU (AMD / Intel) — Using btop

2.2 NVIDIA Dedicated GPU — Using nvidia-smi

Step 3 — Automating GPU Diagnostics

Recommended Tools Summary

Conclusion

Additional Resources

Rescuing Legacy Hardware: Installing Linux on Early UEFI Systems (Debian 13 Case Study)

TL;DR

Context: When a Simple Reinstall Fails

Early UEFI Is Not Modern UEFI

Why Several Modern Distros Failed

Ubuntu 24.04 / Linux Mint 22 / Zorin OS 17

Why Debian 13 Worked

Tested Installation Procedure (Legacy Mode)

Prerequisites

Disk Preparation

Installation

Key Technical Takeaway

Conclusion

References

🛡️ Securing Clawdbot (Moltbot): Essential Hardening for AI Agents with System Access

⚠️ Why Security Is Non-Negotiable with Agentic AI

✅ 1. Use a Separate Machine or Environment

✅ 2. Create Separate Accounts for the Bot

✅ 3. Restrict Who Can Message the Bot

✅ 4. Lock Down the Gateway WebSocket (Local Auth)

✅ 5. Enable Logging and Redact Sensitive Data

✅ 6. Include Security Rules in the System Prompt

✅ 7. Run the Built-In Security Audit

✅ 8. Keep Models and Plugins Up to Date

🚨 Warning Signs Your System May Be Compromised

🔐 Final Thoughts

🚨 ClawdBot (Moltbot): Powerful AI Agents, Real Automation… and Real Risks

What is ClawdBot / Moltbot?

Why Did It Go Viral?

But Here’s the Problem: Full System Access

What Could Go Wrong?

🔓 Prompt Injection

🗝️ Credential Exposure

📂 File System Damage

🌐 Network Abuse

Experts Are Not Saying “Don’t Use It”

Name Change: ClawdBot → Moltbot

So… Should You Use It?

Next Step: How to Use Moltbot Safely

Final Thoughts

How to Build *The Rust Programming Language* Book Locally on Linux

Introduction

Why Build the Book Locally?

Step 1: Installing Rust

How to Build The Rust Programming Language Book Locally on Linux

What Is `pipx`?

Examples of CLI Tools Installed with `pipx`

Step 1: Install `pipx`

Install `pipx` via pacman