Hoje comecei a explorar o VoidPuppy64 no hardware real. Na leitura do que vem a ser o dito sistema entendo que VoidPuppy é o casamento estranho entre o Puppy (leve, modular, feito pra rodar em qualquer tralha velha) e o Void Linux (minimalista, rolling release, tudo na base do xbps). Essa mistura dá uma distro pequena, rápida e, claro, que exige mais atenção.

Sistema que nunca tem versões fixas, denominadas “rolling release”; atualizado continuamente sem reinstalar, me parece bom… até quando, não sei!

8. Instalação Frugal

Mesmo instalado no HD, o VoidPuppy roda em modo frugal, com camadas sobrepostas (AUFS). > mount | grep “on /” > unionfs on / type aufs (rw,relatime,si=6a0fd99e3eb79185)

• O sistema não é realmente instalado no disco inteiro.
• Ele copia os arquivos principais do sistema (vmlinuz, initrd.gz, puppy.sfs, zdrv.sfs, etc.) para uma pasta, tipo /puppy ou /boot/voidpup/.
• Depois, tudo roda carregado na RAM, e as alterações ficam guardadas num arquivo de persistência (savefile ou savefolder).
• Na prática,é sistema “live”, mas com estado persistente — meio híbrido entre live USB e instalação normal.
• Se der pau, é só apagar o savefile e começa do zero.

O processo que inicia o sistema é extremamente minimalista, suficiente para tarefas leves e multitarefa de navegador + apps web. > ps -p 1 -o comm= > busybox

find / -name init 2>/dev/null /usr/share/alsa/init /initrd/init /initrd/pup_ro2/sbin/init /initrd/pup_ro2/usr/share/alsa/init /initrd/mnt/dev_save/vpup6422.02frugal/vpup64save/initrd/init /sbin/init

Observações: - Em FHS puro, você esperaria init apenas em /sbin/init. - No Puppy/VoidPuppy, init está espalhado em múltiplos lugares, incluindo /initrd e subpastas do savefile. - Isso mostra a natureza modular e frugal do sistema: arquivos do sistema principal, init e módulos estão onde o Puppy acha melhor, não no layout tradicional de Linux.

Portanto, não se aplica a “copia os arquivos principais para /puppy ou /boot/voidpup”, porque o Puppy mantém essas camadas em lugares separados (/initrd, .sfs, RAM, savefile), não em um diretório fixo tipo /boot.

Procura por arquivos de configuração em /root

find /root -type f | grep -i config /root/.config/lxterminal/lxterminal.conf /root/.config/micro/bindings.json /root/.config/geany/session.conf … /root/.config/save-exclude.lst /root/.oh-my-bash/.git/config

• Configurações não estão em /etc como em FHS tradicional.
• Ficam centralizadas em /root/.config ou no savefile.
• Isso reforça que o Puppy usa um layout próprio, baseado em modularidade e persistência separada, não em hierarquia padrão de Linux.

Panorama do sistema: >/ (root do sistema - AUFS)

/ (root do sistema - AUFS)
├─ camada base (.sfs)               → sistema principal, somente leitura
│   ├─ kernel, libs, comandos básicos
│   └─ aplicativos essenciais
├─ camada de módulos (.sfs apps)    → aplicativos grandes montados dinamicamente
│   ├─ Palemoon.sfs
│   ├─ LibreOffice.sfs
│   └─ outros .sfs que montar
├─ camada temporária (RAM)          → alterações da sessão atual
│   ├─ configs modificados
│   ├─ arquivos criados temporariamente
│   └─ operações do dia-a-dia
└─ camada persistente (savefile)    → alterações entre reinicializações
    ├─ configs salvos
    ├─ arquivos criados permanentemente
    └─ personalizações do usuário

Explicação prática: - Camada base (.sfs): é só leitura, garante que o sistema sempre tenha uma base limpa. - Módulos .sfs: programas grandes não “poluem” o sistema, são carregados sob demanda. - RAM (camada temporária): tudo que você altera durante a sessão vai para cá. - Savefile/savefolder: quando salvo, tudo que estava na RAM é gravado aqui e persistirá no próximo boot.

Fluxo de trabalho resumido: - Liga o computador → AUFS monta camadas - Alterações vão para RAM - Ao desligar, GUI pergunta se quer salvar - Se salvar → alterações vão para o savefile

Próximo boot → AUFS combina .sfs + RAM + savefile para iniciar a sessão persistente

9. Savefile — Persistência manual no VoidPuppy

O savefile é o arquivo onde o Puppy/VoidPuppy guarda todas as alterações feitas durante a sessão. Até ser criado e montado, tudo que você faz fica apenas na RAM (camada temporária AUFS).

• Passo 1. Verificar se algum savefile está montado: > mount | grep save > /dev/sda3 on /initrd/mnt/dev_save type ext4 (rw,noatime)

Há uma partição montada mas não é um savefile ativo do Puppy. Esse é apenas o ponto de montagem do dispositivo/partição onde você poderia criar o savefile.

• Passo 2 — Criar o arquivo do savefile (1Gb): > dd if=/dev/zero of=voidpuppy_savefile.fs bs=1M count=1024 (Pode ser ajustado o “count” para maior ou menor conforme a necessidade).

• Passo 3 — Formatar o savefile > mkfs.ext4 voidpuppy_savefile.fs Isso prepara o arquivo para receber dados como um sistema de arquivos normal.

• Passo 4 — Criar ponto de montagem e montar o savefile > mkdir -p /mnt/save > mount -o loop /initrd/mnt/dev_save/voidpuppy_savefile.fs /mnt/save Tudo copiado ou criado aqui será persistente.

• Passo 5 — Testar o savefile > echo “teste de persistência” > /mnt/save/teste.txt > cat /mnt/save/teste.txt

Reinicie o sistema e monte novamente o savefile: > mount -o loop /initrd/mnt/dev_save/voidpuppy_savefile.fs /mnt/save > cat /mnt/save/teste.txt

10. Monitoramento em tempo real

Para observar uso real do sistema, executei: > vmstat 1

Cenário de teste: - Browser Neocities (edição do site) - WhatsApp Web - Terminal ativo

r b swpd free buff cache si so bi bo in cs us sy id wa st gu 9 0 0 294832 39364 2241164 0 0 0 0 1416 2917 84 12 3 0 0 0 1 0 0 295196 39364 2240144 0 0 0 0 1662 2348 78 12 11 0 0 0 1 0 0 304072 39364 2239992 0 0 0 2680 1442 2053 17 5 78 0 0 0

Interpretação resumida: - swpd = 0 → Nenhum uso de swap. A RAM dá conta de tudo. - free ~295 MB / cache ~2.2 GB → Kernel usa cache de forma agressiva, acelerando I/O. - si/so = 0 → Nenhum tráfego de swap, boa eficiência de memória. - bi/bo próximos de 0 → Disco quase ocioso, sem I/O intenso. - us/sy/id = 84/12/3% → CPU em uso ativo, sem gargalo. - wa (wait) = 0% → Nenhuma espera por disco, ótimo sinal de responsividade.

Conclusão: Mesmo em hardware de 2011, o VoidPuppy mostra estabilidade e gerenciamento eficiente de recursos. O kernel prioriza cache e mantém o sistema reativo, sem queda perceptível de desempenho durante multitarefa leve.