DEV Community: Igor Giamoniano

I built a Pix library for Elixir (and one cent proved it works)

Igor Giamoniano — Tue, 29 Sep 2026 00:31:02 +0000

Over the last few months I became a bit of a compulsive open source contributor. Translating Linux kernel documentation into Portuguese, a merged PR in uutils/coreutils, a few fixes in Elixir libraries I had used before. Always the same routine: find a problem in someone else's project, understand it, fix it, wait for review.

Then a different itch showed up: instead of fixing other people's libraries, build my own.

This post is about that. How I built pix_brcode, a Pix library for Elixir, over a weekend, tested it with real money (R$ 0.01, don't judge me) and published it on Hex. And about the bug that only showed up once a real bank got involved.

What is Pix, and why a library for it

If you're not from Brazil, you've probably never heard of Pix. It's the instant payment system created by Brazil's Central Bank in 2020, and it took over the country: it's free for individuals, settles in seconds, works 24/7, and today it's how Brazilians pay for everything from coffee to rent.

Most Pix payments start with a QR code, or with its text version, the "copia e cola" (copy and paste) code: a long string starting with 000201 that you paste into your bank app. Everyone uses it every day, and almost nobody knows what's inside it.

In the JavaScript world this is a solved problem: pix-utils on npm generates and parses Pix codes and gets over 60k downloads a month. I went looking for the equivalent on Hex, Elixir's package manager, and couldn't find a maintained one.

So I put the two things together: a big, mature library to use as a reference, and an empty spot in the ecosystem I wanted to fill. I decided to build a "pix-utils" for Hex, or, as I preferred to call it, pix_brcode.

What's inside a Pix code

That string is a BR Code: an international payment QR code standard (EMVCo's QR Code Specification, Merchant-Presented Mode) with Pix-specific fields.

The structure is simpler than it looks. Everything is TLV: a 2-digit ID, a 2-digit length, then the value.

00 02 01                       → payload format: "01"
26 58 0014br.gov.bcb.pix0136…  → Pix account (with subfields inside!)
52 04 0000                     → merchant category
53 03 986                      → currency: Brazilian real
54 04 0.01                     → amount
58 02 BR                       → country
59 04 Igor                     → receiver name
60 09 Sao Paulo                → city
62 07 0503***                  → txid (transaction id)
63 04 F6CE                     → CRC16

Look at field 26: its value is another TLV, holding the Pix identifier (br.gov.bcb.pix) and the key. TLV inside TLV.

And the last field, 63, is a CRC16: a checksum over everything before it. If someone copies the code missing one character, the CRC doesn't match and the bank app rejects it.

(Important side note: a CRC is not security. It catches accidental errors, not fraud. Anyone can recompute it.)

The decisions that made the weekend worth it

Zero dependencies

Installing pix_brcode pulls in nothing else. That had a cost: Erlang only ships CRC32, so the CRC16 was written by hand in about 20 lines, using Elixir's binary pattern matching:

defp crc(<<byte, rest::binary>>, acc) do
  acc = Enum.reduce(1..8, bxor(acc, byte <<< 8), fn _, acc -> shift(acc <<< 1) end)
  crc(rest, acc)
end

defp crc(<<>>, acc), do: acc

Adding a dependency for 20 lines would be trading a small problem for a permanent one.

Money is never a float

pix-utils takes the amount as a JavaScript number, which is a float. And floats with money are how you end up seeing 0.1 + 0.2 = 0.30000000000000004 on someone's bill.

In pix_brcode, the amount is either an integer in cents (1050 becomes "10.50") or an exact string ("10.50"). The conversion is done on text, with no division at all.

Strict in what you send, liberal in what you accept

When generating, the library is strict: a name longer than 25 characters is an error instead of being silently truncated (imagine the payer's bank app showing the wrong name). When parsing, it accepts whitespace and line breaks around the code, because real copy-and-paste comes dirty from WhatsApp.

That principle has a name, Postel's law. And it was about to be tested sooner than I expected.

The moment of truth: real money

Tests passing, Credo clean, docs generated. Only one test left that really matters: a bank app accepting the code.

The first try failed in all three banks I tested. Itaú, Nubank and Mercado Pago: "Invalid QR Code".

For a minute I thought the weekend was wasted. It wasn't: I had used a made-up Pix key. When you paste a static Pix code, the app looks the key up in the Central Bank's directory. Unknown key, rejected code. The test was wrong, not the library.

I generated it again with my real Itaú random key and an amount of one cent:

PixBrcode.encode(%{key: "my-real-key", amount: 1,
                   merchant_name: "Igor", merchant_city: "Sao Paulo"})

Pasted it into Nubank. My name showed up, R$ 0.01. Paid. It landed in my Itaú account instantly.

The best-invested cent of my life.

The bug no test caught

The reverse path was still missing: generate a code in the bank app and parse it with the library. Pix > Receive on Nubank, copy, paste into the terminal:

iex> PixBrcode.decode("00020126580014BR.GOV.BCB.PIX0136…")
{:error, :invalid_gui}

BR.GOV.BCB.PIX. In uppercase.

The Central Bank's manual writes br.gov.bcb.pix in lowercase, and the library compared the exact text. Nubank sends it uppercase. So does Itaú. All my tests passed because they all followed the manual to the letter, and the banks don't.

The fix was one line: compare case-insensitively when parsing, and keep generating lowercase, as the manual says. Postel again: strict in what you send, liberal in what you accept.

The real codes showed other differences too: Nubank includes the postal code (field 61) and puts part of the account holder's tax ID in the receiver name; Itaú doesn't. The library's tests now use payloads with the same layout as the real ones, but with fake data. (Your partial tax ID in a public repo is not a great idea, and I learned that before making the mistake.)

The lesson: the spec is the minimum. Real systems have variations that only show up with real data.

A second opinion before publishing

Before pushing to Hex, I had an AI agent do an independent code review: a fresh session, with no context from the development, reading everything from scratch. Nothing blocked the release, but it came back with four good findings:

the amount field didn't enforce the spec's 13-character limit;
decode(nil) raised an exception, while the README promised always {:ok, _} or {:error, _};
text with invalid bytes also crashed the library;
emoji in the name got through, and since each emoji takes several bytes, the length declared in the TLV was wrong for other parsers.

All four were fixed before v0.1.0. Name, city and description must now be ASCII after removing accents (São João becomes Sao Joao, and ☕ is an error).

What's next

v0.1.0 generates and parses static and dynamic Pix codes, validates keys (tax IDs, phone, e-mail, random key) and runs CI on three Elixir versions. Next on the list: typespecs, more tolerant key parsing and a CHANGELOG. And there's another idea in the queue: Brazilian boleto bank slips, which also have no package on Hex.

If you work with Elixir and Pix, try the library and tell me what breaks. Issues and PRs are very welcome:

Fixing other people's libraries taught me to read code. Building my own taught me that the manual is only the start of the conversation.

This post was originally published in Portuguese on Coisa de Dev.

The bug nobody fixed for 4 years (and how it got me my first Contributor badge)

Igor Giamoniano — Tue, 01 Sep 2026 22:35:52 +0000

Have you ever opened the issues tab of an open source project, stared at the list, and closed it?

I have. More than once.

The feeling is always the same: "this is for grown-ups, I'm not good enough to touch it". So you close the tab, go back to your side project, and contributing becomes something you'll do when you're "ready".

Spoiler: you'll never be ready. I started by fixing a footer that broke on mobile.

The project and the bug

TimeConv is a simple time converter: you give it a date and it hands you back UTC, seconds, or whatever timezone you asked for. Static site, hand-written HTML and CSS, no framework.

Issue #41 said the footer broke on mobile. Opened in August 2022. Four people passed through it over the years, diagnosed the problem, agreed with the diagnosis...

And not one of them opened a PR.

That's the kind of issue I recommend if you're starting out: old, already diagnosed by other people, and with nobody working on it. Half the work is done and the odds of duplicating someone's effort are low.

The CSS bug that wasn't a CSS bug

The original code did this:

footer {
  position: absolute;
  height: 15vh;
  bottom: 0;
}

Absolutely positioned footer, pinned to the bottom. Works beautifully — until the page has enough content to scroll. Then the footer floats in the middle of your text, because bottom: 0 is relative to the viewport, not to the content.

The modern fix is the flexbox sticky footer: make body a flex column with min-height: 100vh, and give the footer margin-top: auto, which pushes it into whatever space is left over.

I swapped it, tested it, and... two pages didn't budge.

Here's the part I didn't see coming, and the most useful thing I took from this contribution: margin-top: auto only pushes an element if it's a direct child of the flex container. In credits.html the footer sat four levels deep inside a .row — which is a horizontal flex container. And in utcsecondstodatetime.html it was literally outside <body>.

So I opened the HTML of those two files and found a duplicated <html>, orphan </div>s, and tags closing out of order. The file was broken badly enough that prettier couldn't even parse it.

Which means: the issue was filed as a CSS bug, and no amount of CSS was ever going to fix it without touching the HTML. That's why four people diagnosed it and nobody shipped — the diagnosis was only half right.

Final PR: 7 files, 175 lines added, 174 removed.

The red check that almost killed it

PR opened, and CI lights up: Lint Code Base failed.

The beginner reflex (mine included) is to run prettier --write across the repo and push everything green. Don't. That would have added ~138 lines of reindentation to a 7-file PR, and the reviewer would have had to separate the fix from the formatting.

What I did instead was pull the original files from main and run the linter against them:

npx prettier --check docs/
npx htmlhint docs/

Result: the original files already failed. And utcsecondstodatetime.html on main didn't even parse. htmlhint reported 18 errors on the original versus 0 on mine.

I posted that in the PR, with the output from both sides. That is precisely what unblocked the merge — the maintainer could see the red was inherited instead of taking my word for it.

It's a rule for me now:

An inherited red check gets explained with reproduced evidence, not fixed by growing the PR.

Three weeks after opening it (and one polite ping along the way, because maintainers of small projects do go quiet), I got an "Awesome, LGTM!" and the merge.

Hands on: test a static site in 30 seconds

No Node, no build step, nothing:

git clone https://github.com/ArjunSharda/TimeConv.git
cd TimeConv/docs
python3 -m http.server 8000

Open http://localhost:8000, hit F12, turn on the device toolbar and test at 320, 375 and 768 pixels wide. Test one short page and one long page — a footer bug only shows up in one of them.

That's the entire test loop for a static-site contribution. Really.

"But that's just CSS, it doesn't count"

It counts. And let me lay out both sides, because this choice is yours.

Small project. Upside: the maintainer actually reads your PR, the codebase fits in your head, and you get to close the full issue → PR → merge loop, which is where the learning lives. Downside: little reach, sometimes an inactive maintainer, and a process too informal to teach you rigor.

Large project. Upside: serious CI, hard review, documented conventions — you learn the craft. Downside: long review queues, and a real chance someone fixes the bug before you do (that happened to me on another project, and it's an article of its own).

I don't think there's a right side. I think starting small and moving up is kinder to your motivation.

Wrapping up

Seven files, 175 lines added, zero lines of complex logic. Result: a Contributor badge and a four-year-old issue closed.

What was blocking that issue wasn't technical difficulty. It was that nobody had opened the HTML.

Your turn: open the issues tab of a project you actually use, filter by is:issue is:open sort:created-asc, and look at the oldest ones. One of them is waiting for somebody to open the file.

And if you do it, brace yourself for one thing: the merge isn't the end. After mine landed I got excited and kept poking around the site — and while testing the pages in the browser, I noticed the converters only worked once. A second conversion needed a page reload.

There were two bugs. They hid each other, with a side effect that pushed whatever the user typed straight into their browser history.

That's the next article.

Author's note: this was my first contribution to TimeConv, merged in August 2026. I'm documenting every open source contribution I make in this series. If you contribute to open source too, I'd like to hear about it.

References

Cava segfaulting inside WezTerm (Flatpak)? Diagnosis and fix in one command

Igor Giamoniano — Fri, 12 Jun 2026 18:06:04 +0000

cava runs fine in any terminal — but inside WezTerm installed via Flatpak it crashes with:

Segmentation fault (core dumped)

If that's what brought you here, the quick fix is right below. The full diagnosis comes after, for those who want to understand why.

⚡ TL;DR — Fix in two commands

flatpak update org.wezfurlong.wezterm
flatpak override --user org.wezfurlong.wezterm --device=all

Close all WezTerm windows and reopen it. cava should work normally now.

⚠️ Security tradeoff: --device=all grants WezTerm access to all system devices — including camera and microphone, not just audio. If that's a concern in your environment, the safer alternative is to use the native WezTerm build, which doesn't have this restriction by design.

🔍 What's happening under the hood

Why does WezTerm Flatpak cause the crash?

Flatpak runs WezTerm inside a sandbox that isolates the process from the host system. cava tries to enumerate available audio devices (ALSA/PipeWire) right at startup — without access to those device nodes, it receives an invalid pointer and segfaults.

That's why other terminals (GNOME Terminal, Kitty, etc.) don't have this problem: they have unrestricted access to the system. --device=all fixes exactly that: it grants access to the audio device nodes cava needs to initialize.

As a secondary hypothesis (not directly confirmed), the sandbox may also modify environment variables that cava uses to detect the audio backend.

Confirming with GDB

Want to see the full backtrace? Expand here.

Inside WezTerm, run:

gdb cava

When prompted, accept debuginfod with y. Then:

(gdb) run

When the crash occurs:

(gdb) bt

The output should look something like this:

Program received signal SIGSEGV, Segmentation fault.
__strncmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
283             VMOVU   (%rdi), %ymm0
(gdb) bt
#0  __strncmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
#1  0x0000555555559cfe in main (argc=, argv=)
    at /usr/src/debug/cava-0.10.2-7.fc44.x86_64/cava.c:297

The crash happens inside __strncmp_avx2 — a glibc string comparison function — called by cava at line 297. The pointer passed in is null or points to invalid memory, which indicates that cava failed to retrieve valid information about the audio devices and segfaulted when trying to use it.

✅ Step-by-step fix

1. Update your packages

sudo dnf upgrade cava          # Fedora
flatpak update org.wezfurlong.wezterm

2. Grant device access

flatpak override --user org.wezfurlong.wezterm --device=all

3. Fully restart WezTerm

Close all windows and reopen. Ctrl+Shift+R is not enough — Flatpak permission changes only take effect after a full restart.

4. Test it

cava

🎉 Working? You're done. If not, see the alternatives below.

🖱️ Alternative: Flatseal

Prefer a GUI for managing Flatpak permissions?

flatpak install flathub com.github.tchx84.Flatseal

Open Flatseal → select WezTerm → go to the Device section → enable All devices → restart WezTerm. The result is identical to the command above.

⚠️ If it still doesn't work

Audio service not running: check if PipeWire is active:

systemctl --user status pipewire
# If inactive:
systemctl --user start pipewire

Rendering issue: add this to your ~/.wezterm.lua:

config.front_end = "Software"

⚠️ This option may cause slowness or even prevent WezTerm from opening on some systems. Use with caution.

🔄 Last resort: native WezTerm

If nothing works — or if the --device=all tradeoff isn't acceptable — the native build solves it definitively: no sandbox, no device restrictions.

The official documentation covers all options: AppImage, .deb/.rpm packages, and building from source.

📌 Summary

Solution	Complexity	Keeps Flatpak?
`flatpak override --device=all`	⭐ Low	✅
Flatseal (GUI)	⭐ Low	✅
Check PipeWire	⭐⭐ Medium	✅
`front_end = "Software"`	⭐⭐ Medium	✅
Install native build	⭐⭐ Medium	❌

The root cause is the Flatpak sandbox blocking cava's access to audio device nodes at startup. Releasing that access with --device=all resolves it in almost every case — and you keep all the benefits of Flatpak.

📝 Based on real experience on Fedora 44+ with WezTerm (Flatpak) and cava 0.10.2.

Cava com segfault no WezTerm (Flatpak)? Diagnóstico e solução em um comando

Igor Giamoniano — Fri, 12 Jun 2026 17:49:28 +0000

O cava roda normalmente em qualquer terminal — mas dentro do WezTerm instalado via Flatpak ele morre com:

Segmentation fault (core dumped)

Se você chegou aqui com esse problema, a solução rápida está logo abaixo. O diagnóstico detalhado vem depois, para quem quiser entender o porquê.

⚡ TL;DR — Solução em dois comandos

flatpak update org.wezfurlong.wezterm
flatpak override --user org.wezfurlong.wezterm --device=all

🔍 O que está acontecendo por baixo dos panos

Por que o WezTerm Flatpak causa o crash?

O Flatpak roda o WezTerm dentro de um sandbox que isola o processo do sistema hospedeiro. O cava tenta enumerar os dispositivos de áudio disponíveis (ALSA/PipeWire) logo na inicialização — sem acesso a esses nós de dispositivo, recebe um ponteiro inválido e segfaulta.

É por isso que outros terminais (GNOME Terminal, Kitty, etc.) não têm o problema: eles têm acesso irrestrito ao sistema. O --device=all resolve exatamente isso: libera o acesso aos dispositivos de áudio que o cava precisa para inicializar.

Como hipótese secundária (não confirmada diretamente), o sandbox também pode modificar variáveis de ambiente que o cava usa para detectar o backend de áudio.

Confirmando com GDB

Quer ver o backtrace completo? Expanda aqui.

Dentro do WezTerm, execute:

gdb cava

Quando aparecer a pergunta, aceite o debuginfod com y. Depois:

(gdb) run

Ao ocorrer a falha:

(gdb) bt

A saída deve ser parecida com esta:

Program received signal SIGSEGV, Segmentation fault.
__strncmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
283             VMOVU   (%rdi), %ymm0
(gdb) bt
#0  __strncmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
#1  0x0000555555559cfe in main (argc=, argv=)
    at /usr/src/debug/cava-0.10.2-7.fc44.x86_64/cava.c:297

O crash ocorre em __strncmp_avx2 — uma função de comparação de strings da glibc — chamada pelo cava na linha 297. O ponteiro passado é nulo ou aponta para memória inválida, o que indica que cava não conseguiu obter informações válidas sobre os dispositivos de áudio e segfaultou ao tentar usá-las.

✅ Solução passo a passo

1. Atualize os pacotes

sudo dnf upgrade cava          # Fedora
flatpak update org.wezfurlong.wezterm

2. Conceda acesso a dispositivos

flatpak override --user org.wezfurlong.wezterm --device=all

3. Reinicie o WezTerm completamente

Feche todas as janelas e reabra. Ctrl+Shift+R não é suficiente — a permissão do Flatpak só entra em vigor com um reinício completo.

4. Teste

cava

🎉 Funcionou? Pronto. Se não, veja as alternativas abaixo.

🖱️ Alternativa: Flatseal

Prefere uma interface gráfica para gerenciar permissões do Flatpak?

flatpak install flathub com.github.tchx84.Flatseal

Abra o Flatseal → selecione WezTerm → seção Device → ative All devices → reinicie o WezTerm. O resultado é idêntico ao comando anterior.

⚠️ Se ainda não funcionar

Serviço de áudio inativo: verifique se o PipeWire está rodando:

systemctl --user status pipewire
# Se inativo:
systemctl --user start pipewire

Problema de renderização: adicione ao ~/.wezterm.lua:

config.front_end = "Software"

⚠️ Esta opção pode causar lentidão ou impedir o WezTerm de abrir em alguns sistemas. Use com cautela.

🔄 Último recurso: versão nativa do WezTerm

Se nada funcionar — ou se o tradeoff do --device=all não for aceitável — a versão nativa resolve definitivamente: sem sandbox, sem restrições de dispositivo.

A documentação oficial cobre todas as opções: AppImage, pacotes .deb/.rpm e compilação do fonte.

📌 Resumo

Solução	Complexidade	Mantém Flatpak?
`flatpak override --device=all`	⭐ Baixa	✅
Flatseal (GUI)	⭐ Baixa	✅
Verificar PipeWire	⭐⭐ Média	✅
`front_end = "Software"`	⭐⭐ Média	✅
Instalar versão nativa	⭐⭐ Média	❌

A causa é o sandbox do Flatpak bloqueando o acesso do cava aos dispositivos de áudio na inicialização. Liberar esse acesso com --device=all resolve em quase todos os casos — e você mantém todas as vantagens do Flatpak.

📝 Tutorial baseado em experiência real no Fedora 44+ com WezTerm (Flatpak) e cava 0.10.2.

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 🐧