Recolher dados de 12 distros – após cada atualização semanal (ou em certas “datas históricas”) – é uma dessas coisas malucas, que só um “dualbooter / multibooter” renitente poderia imaginar… e gastar tempo para pôr em prática.
Acima: - Informações no Conky, para consulta a qualquer momento – e para documentar em capturas de tela
Pois é! – Não bastava inventar 2 Conky’s “horríveis” (rs), feios bagaray, com o máximo de informações que nenhum pipipi-fetch jamais pensou reunir. – De repente, resolvi que precisava “monitorar”, também, o mau comportamento de alguns desses popopó-fetch.
O foco? – No começo, era monitorar o “surto maluco” do Conky – que de repente passou a indicar um uso “absurdamente alto” de Memória RAM… mas, só em algumas distros!
Até então, eu usava essa informação do Conky para “comparar” o uso de Memória RAM de várias distros. – Mas de repente, não servia mais, porque mudou em algumas distros, e não em outras. – Depois, o Conky fez um plot twist carpado, e começou a indicar números “absurdamente baixos”… como os do free
e do top
(ferramentas “irmãs”, ambas do pacote procps).
Eu precisava de algum “medidor”, que usasse o mesmo cálculo em todas as distros.
Achei que o ideal seria o htop
– que, há muitos anos, usava exatamente o mesmo “cálculo antigo” do Conky. – Mas exibir os números do htop
(dentro do Conky) exigia um malabarismo, com os pacotes aha
e html2text
– coisa que demorei a descobrir. – E demorei ainda mais, para conseguir fazer isso em todas as distros, porque esses 2 pacotes não estavam em todos os repositórios “oficiais”.
Então, incluí (no Conky), também os números indicados pelo free
e pelo top
. – Eu já sabia que essas 2 ferramentas (do procps
) davam números bem menores – que apelidei de “cálculo muito antigo”. – Mas eram uma “tábua de salvação”, naquele momento, porque foram a única coisa que encontrei, que permitia uma comparação de uso de Memória RAM, entre todas as distros.
E fui incluindo, mais… o inxi
, o screenFetch, o Neofetch – em busca do Tesouro Perdido (ou, “à procura dos tais patos bravos”): – Um indicador “confiável” de uso de Memória RAM, e que permitisse uma comparação “consistente”, entre todas as distros.
Acabei chegando à conclusão de que era mais fácil, eu mesmo fazer esse cálculo “novo” – a partir dos números disponíveis em /proc/meminfo
– e que estão lá, exatamente para isso, desde 2014 (Kernel 3.14):
Mem used = MemTotal - MemAvailable
Bastava fazer isso – e mandar às favas todos os outros números – do Conky, do htop
, do free
/ top
, do inxi
, do Neofetch, e daquela tralha toda.
Mas, então, percebi que havia um outro maluco, fazendo essa “requisição” (Pull Request) nas páginas de todas essas “ferramentas”… na maior paciência! – Coisa “de mineiro”, discreto, “na moita”, “trabalhando em silêncio”.
Achei fascinante, esse “modo de ação” – uma demonstração de como “o Linux” se desenvolve e aperfeiçoa – como “um esforço da comunidade”.
Era uma coisa que valia a pena acompanhar. – Era uma chance, boa demais, de “ver a comunidade construindo 1 pequena peça do Linux”.
E, que peça! – O cálculo de uso de Memória RAM – que até então, era “terra de ninguém”, cada um tirando da cartola “seu próprio número” (um “cálculo novo”, um “cálculo antigo”, um “cálculo muito antigo”, e o inxi
, cujo número não se enquadrava em nenhum deles). – Uma “conversa de doidos”, em milhares de fóruns, grupos, comunidades, blogs, sites etc.
Um espanto! – A mais absoluta “inconsciência” (generalizada!) sobre o assunto. – Cada um, se colocando como “o dono da verdade absoluta” – o que despertava a “resistência” de todos os outros, que tivessem uma “verdade” diferente.
Comecei a perceber que a “mineirice” daquele (mineirinho?), “trabalhando em silêncio”, “na moita” – sem nunca “aparecer” (pelo contrário!), zerando seu próprio ego, fazendo-se tão “pequeno” quanto possível – era o último recurso, a única estratégia (sem "ofender o ego de ninguém!), para levar cada desenvolvedor, de cada “ferramenta”, a (finalmente) adotarem um padrão proposto por Linus Torvalds, e que tinha caído em ouvidos moucos, ao longo de nada menos do que 6 anos.
E estava dando certo! – Primeiro, o Conky… depois outra ferramenta… depois outra… Estavam caminhando, uma por uma, para “um rumo comum”.
Quando entendi que a mudança do Conky não era um “bug”, nem um “erro crasso” – e corrigi minha postagem inicial no blog – esse “mineirinho” simplesmente apagou o comentário que tinha feito no meu blog, onde me explicava (num inglês meio trôpego: talvez seja alemão, ou galego, ou indu, vai saber!) o motivo por trás da mudança.
Percebi que era o mesmo “mineirinho” (com outro ID!), que havia tentado me explicar a mesma coisa, em um grupo internacional (com centenas de milhares de membros). – Comecei a rastrear quem era aquele “Wally”, no Blogger e nas redes sociais, e acabei por descobrir que era um dos inúmeros devs do Fedora. – Sozinho, ou após conversar com outro(s) colega(s), assumiu aquela “missão” de botar ordem na bagunça.
Sem alardear “eu sou o rei da cocada preta” – e sem “dar ordens” a ninguém. – Zero “autoritarismo”.
Depois disso, apaguei as referências que eu tinha feito a ele (em respeito à sua opção pelo “anônimo”) – e me concentrei unicamente na proposta do Linus Torvalds, na data (2014), no Kernel (3.14+), no /proc/meminfo
– e principalmente, na fórmula mais simples do universo:
Mem used = MemTotal - MemAvailable
Mas, enfim…
Depois de uns 2 ou 3 anos dessa loucura desvairada, o maluco, aqui, acabou concluindo que também precisava guardar registros em TXT – dos quais possa extrair, copiar, colar, um conjunto completo de “estatísticas em marcha”, mês após mês – até porque, o Google ainda não indexa muito bem aquelas letrinhas miúdas das capturas de tela.
Um TXT com os números de uso de Memória RAM indicados por várias ferramentas diferentes – Conky, free
/ top
, htop
, inxi
, Fastfetch, Neofetch, screenFetch – e as versões destas ferramentas… afinal, elas são “humanas”! Elas erram, se corrigem, às vezes decidem errar mais ainda!, e precisamos saber como se comportavam, em diferentes versões, ao longo do tempo. – Não dava mais para “olhar na tela” (ou num PrtScn) e “anotar manualmente”. São números demais:
Acima: - Informações de uma distro (Arch) no início da sessão, ainda sem abrir nenhum aplicativo
Registrar, também, as versões de cada distro, do Plasma, do Frameworks, do Qt (sim, só uso KDE!). – E por que não?.. a versão do Gimp, do Chrome / Chromium, do LibreOffce etc. – “O Céu é o Limite”, mas… vou com calma, para não perder o foco.
Acima: - script RAM.sh, para registrar os números indicados por várias ferramentas, sobre o uso de Memória RAM
Os dados de uso de Memória RAM de cada distro, eu já tinha equacionado, com um script “RAM.sh” – que agendei pelo crontab
para ser executado 10 minutos após o boot. – Eu ia tomar um café, lavar uma louça, conversar um tiquim com os cachórros etc., enquanto os bytes cuidavam de tudo.
Depois de mais 3 minutos, o crontab
executava outro script – que recolhia as versões das ferramentas utilizadas – pois o valor da “informação” depende da “versão” da ferramenta que nos dá esta (suposta) informação.
Desde 2016, venho observando o comportamento de várias distros – e sei que algumas reduzem seu uso de Memória RAM até 6 ou 7 minutos “idle” (sem uso), após o boot. – Exceção é o Redcore, cujo uso de Memória RAM aumenta de modo gradual, lento, porém seguro, até os 10 minutos “idle” (pelo menos).
Acontece que é muito incômodo, esperar 10 + 3 minutos após o boot de 10 distros, uma depois da outra. Isso exige 3 horas! – sem poder usar o computador – mas também, sem me afastar por completo, para fazer outras coisas.
É muito mais prático registrar todos os dados aos 5 minutos uptime (idle). – É tempo mais do que suficiente para tomar 1 café, dar bom-dia aos cachórros, olhar as nuvens, e voltar ao PC, para prosseguir com o registro.
Então, esta semana, reduzi os tempos – mesmo com a perda de alguma “preciosidade” que me aguardasse após os 5 minutos iniciais – e aproveitei para configurar o “Sleep” geral após 10 minutos “idle” (em vez de aos 15 minutos, como antes):
$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 300; bash RAM.sh
@reboot sleep 360; bash VERSIONS.sh
@reboot sleep 420; find ~/.cache/ -type f -atime +365 -delete
Antes do Plasma 6, eu usava apenas “Desligar a tela”. – Agora, adotei o “Sleep”.
Meu consumo de energia evoluiu assim – com o PC desktop ligado 24 horas / dia – nos 7 dias da semana:
-
4,6 kWh / dia, nos 9 meses antes de comprar um NoBreak – Mínimo 4,2 kWh, máximo 5,0 kWh
-
5,0 kWh / dia, nos últimos 7 meses, já com o NoBreak “básico” (onda quadrada) – Mínimo 4,5 kWh, máximo 5,6 kWh. Portanto, aumentou +/- 0,3 a 0.6 kWh / dia.
-
3,4 kWh / dia, no último mês, com o “Sleep” – uma economia de 1,6 kWh / dia; ou 48 kWh ao mês. – Falta tirar uma média dos próximos meses – e uma média dos mesmos meses em anos anteriores, pois há variações sazonais, conforme o calor ou o frio (chuveiro), dias de sol claro ou nublados (lâmpadas) etc.
Acima: - Um segundo script VERSIONS.sh, para registrar as versões da distro, do Plasma etc.
A cada semana, crio uma pasta diferente, para reunir os dados recolhidos das várias distros – mas seria muito chato, abrir 10 arquivos, para tentar comparar “detalhes minuciosos”:
Acima: - Pasta com os dados das várias distros – para serem reunidos por um script Summary.sh
Criei, então, um script
… “de amador”! – Um “Summary.sh” – que extrai os dados registrados de todas as distros, e me apresenta um resumo bem organizado, que batizei como “Summary.txt”:
Acima: - script Summary.sh, para reunir os dados de todas as distros, em tabelas fáceis de ler
O resultado – após um “remake” nos últimos dias – me agradou bastante:
------------- Folder -------------------
Conky-RAM_2024-05-10_remake
--------------- Date -------------------
RAM_01-openSUSE_: system boot 2024-05-11 09:37
RAM_02-Arch_____: system boot May 10 20:29
RAM_03-Debian___: system boot 2024-05-11 05:09
RAM_04-Fedora___: inicialização do sistema 2024-05-11 04:24
RAM_06-PCLinuxOS: system boot 2024-05-11 09:27
RAM_07-Mageia___: system boot 2024-05-11 01:21
RAM_09-Void_____: system boot May 10 22:48
RAM_10-Manjaro__: system boot 2024-05-10 22:05
RAM_12-MXLinux__: system boot 2024-05-11 00:19
RAM_13-Neon_6___: system boot 2024-05-11 00:02
10
--------------- New Calc ---------------
RAM_01-openSUSE_:1155 MiB (MemInfo T-A)
RAM_02-Arch_____:1096 MiB (MemInfo T-A)
RAM_03-Debian___:1078 MiB (MemInfo T-A)
RAM_04-Fedora___:1208 MiB (MemInfo T-A)
RAM_06-PCLinuxOS:907 MiB (MemInfo T-A)
RAM_07-Mageia___:1053 MiB (MemInfo T-A)
RAM_09-Void_____:903 MiB (MemInfo T-A)
RAM_10-Manjaro__:1049 MiB (MemInfo T-A)
RAM_12-MXLinux__:1132 MiB (MemInfo T-A)
RAM_13-Neon_6___:1135 MiB (MemInfo T-A)
10
----------------- Conky ----------------
RAM_01-openSUSE_:Conky (Mem) 1.13GiB
RAM_02-Arch_____:Conky (Mem) 1.07GiB
RAM_03-Debian___:Conky (Mem) 1.05GiB
RAM_04-Fedora___:Conky (Mem) 1,18GiB
RAM_06-PCLinuxOS:Conky (Mem) 907MiB
RAM_07-Mageia___:Conky (Mem) 1,03GiB
RAM_09-Void_____:Conky (Mem) 904MiB
RAM_10-Manjaro__:Conky (Mem) 1.03GiB
RAM_12-MXLinux__:Conky (Mem) 1.11GiB
RAM_13-Neon_6___:Conky (Mem) 1.11 GiB
10
---------------- free ------------------
RAM_01-openSUSE_:Mem: 15840 1152 13649 176 1487 14688
RAM_02-Arch_____:Mem: 15842 1096 14080 185 1124 14745
RAM_03-Debian___:Mem: 15847 1078 14318 198 920 14768
RAM_04-Fedora___:Mem: 15831 1208 13783 163 1282 14622
RAM_06-PCLinuxOS:Mem: 15857 445 14627 194 784 14950
RAM_07-Mageia___:Mem: 15850 1056 14231 179 1018 14793
RAM_09-Void_____:Mem: 15843 903 14596 192 802 14940
RAM_10-Manjaro__:Mem: 15851 1049 14323 189 946 14802
RAM_12-MXLinux__:Mem: 15837 1135 14286 179 869 14702
RAM_13-Neon_6___:Mem: 15829 704 14066 155 1059 14691
10
--------------- top --------------------
RAM_01-openSUSE_:MiB Mem : 15840.99+total, 13650.15+free, 1152.555 used, 1487.473 buff/cache
RAM_02-Arch_____:MiB Mem : 15842.1 total, 14080.4 free, 1096.6 used, 1125.0 buff/cache
RAM_03-Debian___:MiB Mem : 15847.2 total, 14318.1 free, 1079.3 used, 920.2 buff/cache
RAM_04-Fedora___:MiB Mem : 15831,5 total, 13783,3 free, 1208,5 used, 1282,2 buff/cache
RAM_06-PCLinuxOS:MiB Mem : 15857.6 total, 14627.5 free, 445.2 used, 784.9 buff/cache
RAM_07-Mageia___:MiB Mem : 15851,0 total, 14230,7 free, 1057,3 used, 1019,0 buff/cache
RAM_09-Void_____:MiB Mem : 15843.8 total, 14595.6 free, 904.5 used, 802.5 buff/cache
RAM_10-Manjaro__:MiB Mem : 15851.7 total, 14322.5 free, 1050.7 used, 946.4 buff/cache
RAM_12-MXLinux__:MiB Mem : 15837.9 total, 14285.2 free, 1136.7 used, 869.5 buff/cache
RAM_13-Neon_6___:MiB Mem : 15829.5 total, 14066.2 free, 704.1 used, 1059.3 buff/cache
10
--------------- htop -------------------
RAM_01-openSUSE_: 880M/15.5G]
RAM_02-Arch_____: 827M/15.5G]
RAM_03-Debian___: 808M/15.5G]
RAM_04-Fedora___: 936M/15.5G]
RAM_06-PCLinuxOS: 639M/15.5G]
RAM_07-Mageia___: 780M/15.5G]
RAM_09-Void_____: 638M/15.5G]
RAM_10-Manjaro__: 779M/15.5G]
RAM_12-MXLinux__: 684M/15.5G]
RAM_13-Neon_6___: 860M/15.5G]
10
--------------- inxi -------------------
RAM_01-openSUSE_: System RAM: total: 16 GiB available: 15.47 GiB used: 1.15 GiB (7.4%)
RAM_02-Arch_____: System RAM: total: 16 GiB available: 15.47 GiB used: 1.09 GiB (7.0%)
RAM_03-Debian___: System RAM: total: 16 GiB available: 15.48 GiB used: 1.1 GiB (7.1%)
RAM_04-Fedora___: System RAM: total: 16 GiB available: 15.46 GiB used: 1.22 GiB (7.9%)
RAM_06-PCLinuxOS: System RAM: total: 16 GiB available: 15.49 GiB used: 938.1 MiB (5.9%)
RAM_07-Mageia___: System RAM: total: 16 GiB available: 15.48 GiB used: 1.06 GiB (6.8%)
RAM_09-Void_____: System RAM: total: 16 GiB available: 15.47 GiB used: 934.3 MiB (5.9%)
RAM_10-Manjaro__: System RAM: total: 16 GiB available: 15.48 GiB used: 1.05 GiB (6.8%)
RAM_12-MXLinux__: RAM: total: 15.47 GiB used: 1.14 GiB (7.4%)
RAM_13-Neon_6___: RAM: total: 15.46 GiB used: 1.14 GiB (7.4%)
10
-------------- Fastfetch ---------------
RAM_01-openSUSE_-Memory: 1.15 GiB / 15.47 GiB (7%)
RAM_02-Arch_____-Memory: 1.06 GiB / 15.47 GiB (7%)
RAM_04-Fedora___-Memory: 1,22 GiB / 15,46 GiB (8%)
RAM_10-Manjaro__-Memory: 1.03 GiB / 15.48 GiB (7%)
4
--------------- Neofetch ---------------
RAM_01-openSUSE_-Memory: 891MiB / 15840MiB
RAM_02-Arch_____-Memory: 821MiB / 15842MiB
RAM_03-Debian___-Memory: 856MiB / 15847MiB
RAM_04-Fedora___-Memory: 945MiB / 15831MiB
RAM_06-PCLinuxOS-Memory: 643MiB / 15857MiB
RAM_07-Mageia___-Memory: 764MiB / 15850MiB
RAM_09-Void_____-Memory: 626MiB / 15843MiB
RAM_10-Manjaro__-Memory: 775MiB / 15851MiB
RAM_12-MXLinux__-Memory: 870MiB / 15837MiB
RAM_13-Neon_6___-Memory: 860MiB / 15829MiB
10
------------- screenFetch --------------
RAM_01-openSUSE_- RAM: 1168MiB / 15840MiB
RAM_02-Arch_____- RAM: 1101MiB / 15842MiB
RAM_03-Debian___- RAM: 1136MiB / 15847MiB
RAM_04-Fedora___- RAM: 1236MiB / 15831MiB
RAM_06-PCLinuxOS- RAM: 912MiB / 15857MiB
RAM_07-Mageia___- RAM: 1032MiB / 15850MiB
RAM_09-Void_____- RAM: 891MiB / 15843MiB
RAM_10-Manjaro__- RAM: 1063MiB / 15851MiB
RAM_12-MXLinux__- RAM: 1180MiB / 15837MiB
RAM_13-Neon_6___- RAM: 1146MiB / 15829MiB
10
=============== VERSIONS ==================
RAM_01-openSUSE_:Linux 6.8.8-1-default
RAM_02-Arch_____:Linux 6.6.30-1-lts
RAM_03-Debian___:Linux 6.7.12-amd64
RAM_04-Fedora___:Linux 6.8.8-300.fc40.x86_64
RAM_06-PCLinuxOS:Linux 6.6.30-pclos1
RAM_07-Mageia___:Linux 6.5.3-desktop-1.mga10
RAM_09-Void_____:Linux 6.6.30_1
RAM_10-Manjaro__:Linux 5.10.211-1-MANJARO
RAM_12-MXLinux__:Linux 6.1.0-10-amd64
RAM_13-Neon_6___:Linux 6.5.0-28-generic
10
---------------- init -------------------
RAM_01-openSUSE_:systemd
RAM_01-openSUSE_-255
--
RAM_02-Arch_____:systemd
RAM_02-Arch_____-255
--
RAM_03-Debian___:systemd
RAM_03-Debian___-255
--
RAM_04-Fedora___:systemd
RAM_04-Fedora___-255
--
RAM_06-PCLinuxOS:sysvinit
RAM_06-PCLinuxOS-3.09
--
RAM_07-Mageia___:systemd
RAM_07-Mageia___-255
--
RAM_09-Void_____:runit
--
RAM_10-Manjaro__:systemd
RAM_10-Manjaro__-255
--
RAM_12-MXLinux__:sysvinit
RAM_12-MXLinux__-3.06
--
RAM_13-Neon_6___:systemd
RAM_13-Neon_6___-249
28
(10 x 3) - 2 = 28
--------------- Plasma ------------------
RAM_01-openSUSE_:KDE Plasma Version: 6.0.4
RAM_02-Arch_____:KDE Plasma Version: 6.0.4
RAM_04-Fedora___:KDE Plasma Version: 6.0.4
RAM_07-Mageia___:KDE Plasma Version: 6.0.4
RAM_13-Neon_6___:KDE Plasma Version: 6.0.4
5
-------------- Frameworks -----------------
RAM_01-openSUSE_:KDE Frameworks Version: 6.1.0
RAM_01-openSUSE_:kf5 KDE Frameworks: 5.115.0
RAM_02-Arch_____:KDE Frameworks Version: 6.1.0
RAM_02-Arch_____:kf5 KDE Frameworks: 5.115.0
RAM_03-Debian___:kf5 KDE Frameworks: 5.107.0
RAM_04-Fedora___:KDE Frameworks Version: 6.1.0
RAM_04-Fedora___:kf5 KDE Frameworks: 5.115.0
RAM_06-PCLinuxOS:kf5 KDE Frameworks: 5.115.0
RAM_07-Mageia___:KDE Frameworks Version: 6.1.0
RAM_07-Mageia___:kf5 KDE Frameworks: 5.115.0
RAM_09-Void_____:kf5 KDE Frameworks: 5.115.0
RAM_10-Manjaro__:kf5 KDE Frameworks: 5.115.0
RAM_12-MXLinux__:kf5 KDE Frameworks: 5.103.0
RAM_13-Neon_6___:KDE Frameworks Version: 6.1.0
RAM_13-Neon_6___:kf5 KDE Frameworks: 5.115.0
15
----------------- Qt ----------------------
RAM_01-openSUSE_:Qt Version: 6.7.0
RAM_01-openSUSE_:kf5 Qt: 5.15.13
RAM_02-Arch_____:Qt Version: 6.7.0
RAM_02-Arch_____:kf5 Qt: 5.15.13
RAM_03-Debian___:kf5 Qt: 5.15.10
RAM_04-Fedora___:Qt Version: 6.7.0
RAM_04-Fedora___:kf5 Qt: 5.15.13
RAM_06-PCLinuxOS:kf5 Qt: 5.15.6
RAM_07-Mageia___:Qt Version: 6.6.2
RAM_07-Mageia___:kf5 Qt: 5.15.12
RAM_09-Void_____:kf5 Qt: 5.15.11
RAM_10-Manjaro__:kf5 Qt: 5.15.12
RAM_12-MXLinux__:kf5 Qt: 5.15.8
RAM_13-Neon_6___:Qt Version: 6.7.0
RAM_13-Neon_6___:kf5 Qt: 5.15.13
15
---------------- Gimp ---------------------
RAM_01-openSUSE_:GNU Image Manipulation Program version 2.10.38
RAM_02-Arch_____:GNU Image Manipulation Program version 2.10.38
RAM_03-Debian___:GNU Image Manipulation Program version 2.10.36
RAM_04-Fedora___:Programa de manipulação de imagem do GNU versão 2.10.38
RAM_06-PCLinuxOS:GNU Image Manipulation Program version 2.10.38
RAM_07-Mageia___:GNU Image Manipulation Program version 2.10.38
RAM_09-Void_____:GNU Image Manipulation Program version 2.10.36
RAM_10-Manjaro__:GNU Image Manipulation Program version 2.10.36
RAM_12-MXLinux__:GNU Image Manipulation Program version 2.10.34
RAM_13-Neon_6___:GNU Image Manipulation Program version 2.10.30
10
-------------- Chrome ---------------------
RAM_01-openSUSE_:Google Chrome 124.0.6367.155
RAM_02-Arch_____:Google Chrome 124.0.6367.118
RAM_03-Debian___:Chromium 124.0.6367.118 built on Debian trixie/sid, running on Debian trixie/sid
RAM_04-Fedora___:Google Chrome 124.0.6367.155
RAM_06-PCLinuxOS:Google Chrome 124.0.6367.60
RAM_07-Mageia___:Google Chrome 124.0.6367.201
RAM_09-Void_____:Google Chrome 124.0.6367.118
RAM_10-Manjaro__:Google Chrome 124.0.6367.118
RAM_12-MXLinux__:Google Chrome 124.0.6367.155
RAM_13-Neon_6___:Google Chrome 124.0.6367.201
10
-------------- LibreOffice ----------------
RAM_01-openSUSE_:LibreOffice 24.2.3.2 420(Build:2)
RAM_02-Arch_____:LibreOffice 24.2.3.2 420(Build:2)
RAM_03-Debian___:LibreOffice 24.2.3.2 420(Build:2)
RAM_04-Fedora___:LibreOffice 24.2.3.2 420(Build:2)
RAM_06-PCLinuxOS:LibreOffice 24.2.2.2 d56cc158d8a96260b836f100ef4b4ef25d6f1a01
RAM_07-Mageia___:LibreOffice 24.2.2.2 420(Build:2)
RAM_09-Void_____:LibreOffice 24.2.2.2 420(Build:2)
RAM_10-Manjaro__:LibreOffice 24.2.0.3 420(Build:3)
RAM_12-MXLinux__:LibreOffice 7.4.7.2 40(Build:2)
RAM_13-Neon_6___:LibreOffice 7.3.7.2 30(Build:2)
10
--------------- Conky ---------------------
RAM_01-openSUSE_:conky 1.13.1 compiled for Linux x86_64
RAM_02-Arch_____:conky 1.19.7_pre compiled 2024-02-26 for Linux x86_64
RAM_03-Debian___:conky 1.20.2 compiled for Linux x86_64
RAM_04-Fedora___:conky 1.19.6_pre compiled 2024-02-01 for Linux x86_64
RAM_06-PCLinuxOS:conky 1.19.4_pre compiled 2023-08-29 for Linux x86_64
RAM_07-Mageia___:conky 1.19.8 compiled for Linux x86_64
RAM_09-Void_____:conky 1.19.6 compiled 2024-02-19 for Linux x86_64
RAM_10-Manjaro__:conky 1.19.7_pre compiled 2024-02-26 for Linux x86_64
RAM_12-MXLinux__:conky 1.18.3 compiled 2023-03-07 for Linux x86_64
RAM_13-Neon_6___:conky 1.12.2 compiled 2022-02-23 for Linux x86_64
10
--------------- procps --------------------
RAM_01-openSUSE_:free from procps-ng 3.3.17
RAM_02-Arch_____:free from procps-ng 4.0.4
RAM_02-Arch_____:top from procps-ng 4.0.4
RAM_03-Debian___:free from procps-ng 4.0.4
RAM_03-Debian___:top from procps-ng 4.0.4
RAM_04-Fedora___:free from procps-ng 4.0.4
RAM_04-Fedora___:top from procps-ng 4.0.4
RAM_06-PCLinuxOS:free from procps-ng 3.3.15
RAM_07-Mageia___:free from procps-ng 4.0.4
RAM_07-Mageia___:top from procps-ng 4.0.4
RAM_09-Void_____:free from procps-ng 4.0.4
RAM_09-Void_____:top from procps-ng 4.0.4
RAM_10-Manjaro__:free from procps-ng 4.0.4
RAM_10-Manjaro__:top from procps-ng 4.0.4
RAM_12-MXLinux__:free from procps-ng 4.0.2
RAM_12-MXLinux__:top from procps-ng 4.0.2
RAM_13-Neon_6___:free from procps-ng 3.3.17
17
--------------- htop ----------------------
RAM_01-openSUSE_:htop 3.3.0
RAM_02-Arch_____:htop 3.3.0
RAM_03-Debian___:htop 3.3.0
RAM_04-Fedora___:htop 3.3.0
RAM_06-PCLinuxOS:htop 3.3.0
RAM_07-Mageia___:htop 3.3.0
RAM_09-Void_____:htop 3.3.0
RAM_10-Manjaro__:htop 3.3.0
RAM_12-MXLinux__:htop 3.2.2
RAM_13-Neon_6___:htop 3.0.5
10
--------------- inxi ----------------------
RAM_01-openSUSE_:inxi 3.3.34-00 (2024-04-13)
RAM_02-Arch_____:inxi 3.3.34-00 (2024-04-13)
RAM_03-Debian___:inxi 3.3.34-00 (2024-04-13)
RAM_04-Fedora___:inxi 3.3.34-00 (2024-04-13)
RAM_06-PCLinuxOS:inxi 3.3.34-00 (2024-04-13)
RAM_07-Mageia___:inxi 3.3.34-00 (2024-04-13)
RAM_09-Void_____:inxi 3.3.33-00 (2024-02-06)
RAM_10-Manjaro__:inxi 3.3.34-00 (2024-04-13)
RAM_12-MXLinux__:inxi 3.3.26-00 (2023-03-28)
RAM_13-Neon_6___:inxi 3.3.13-00 (2022-02-22)
10
--------------- Fastfetch -----------------
RAM_01-openSUSE_:fastfetch 2.11.0 (x86_64)
RAM_02-Arch_____:fastfetch 2.11.5-debug (x86_64)
RAM_04-Fedora___:fastfetch 2.9.1 (x86_64)
RAM_10-Manjaro__:fastfetch 2.8.7 (x86_64)
4
--------------- Neofetch ------------------
RAM_01-openSUSE_:Neofetch 7.1.0
RAM_02-Arch_____:Neofetch 7.1.0
RAM_03-Debian___:Neofetch 7.1.0
RAM_04-Fedora___:Neofetch 7.1.0
RAM_06-PCLinuxOS:Neofetch 7.1.0
RAM_07-Mageia___:Neofetch 7.1.0
RAM_09-Void_____:Neofetch 7.1.0
RAM_10-Manjaro__:Neofetch 7.1.0
RAM_12-MXLinux__:Neofetch 7.1.0
RAM_13-Neon_6___:Neofetch 7.1.0
10
--------------- screenFetch ---------------
RAM_01-openSUSE_:e[4mscreenFetche[0m - Version 3.9.1
RAM_02-Arch_____:e[4mscreenFetche[0m - Version 3.9.1
RAM_03-Debian___:e[4mscreenFetche[0m - Version 3.9.1
RAM_04-Fedora___:e[4mscreenFetche[0m - Version 3.9.1
RAM_06-PCLinuxOS:e[4mscreenFetche[0m - Version 3.9.1
RAM_07-Mageia___:e[4mscreenFetche[0m - Version 3.9.1
RAM_09-Void_____:e[4mscreenFetche[0m - Version 3.9.1
RAM_10-Manjaro__:e[4mscreenFetche[0m - Version 3.9.1
RAM_12-MXLinux__:e[4mscreenFetche[0m - Version 3.9.1
RAM_13-Neon_6___:e[4mscreenFetche[0m - Version 3.9.1
10
-------------------------------------------
Há uma certa ordem na sequência dos comandos (no
RAM.sh
e no Conky), pois o screenFetch (por exemplo) altera os números dos comandos executados depois dele (8 comandos em 1 segundo!), por isso, coloquei no final. – Ainda falta verificar se oinxi
ou ohtop
(+aha
+html2text
) afetam o uso de RAM e, portanto, os números dos comandos executados imediatamente depois deles.
Todos esses scripts são “feios”, bobos, “coisa de amador” etc. – Não “possuem” nenhuma das qualidades que distinguem um script “elegante” ou “profissional”. – Nenhum “if / fi”, nem aquelas coisas maravilhosas, que vejo no Stack Exchange ou no Stack Overflow.
Mas oferecem uma informação exata, precisa, bem organizada, e útil (pelo menos, para mim):
- A data e a circunstância (Folder) que tornam essas informações relevantes para mim. – No caso, o “remake” dos scripts: – Eu estava testando uma reorganização dos scripts mais antigos – e resolvi fazer isso, antes das atualizações deste Domingo. – Testei hoje, para ter certeza de que amanhã (Domingo), depois das atualizações semanais, poderei ter um quadro confiável. – Qualquer dúvida, falha etc., examinei e corrigi hoje.
É claro que, “amanhã, ninguém sabe”. – Essas “coisas” mudam o tempo todo, como um bando de crianças traquinas – e precisa ter “vocação”, para lidar com uma creche de 10 distros – que pulam, fazem pipi nas fraldas, mudam e desmudam, “pintam o 7” sem parar.
O comando para obter a versão do LibreOffice, por exemplo, tem sido sempre o mesmo, na maioria das distros – exceto no PCLinuxOS, – onde você precisa saber a versão… para descobrir o comando para descobrir a versão:
# libreoffice7.2 --version >> RAM_06-PCLinuxOS
libreoffice24.2 --version >> RAM_06-PCLinuxOS
- O momento do boot de cada distro – para localizar o PrtScn, caso necessário:
2024-05-11_10-09-42_A-inicio.jpg
2024-05-11_15-51-16_Mx-inicio-apos-Arch-freeze.jpg
2024-05-11_18-17-26_V-inicio-apos-Freeze-MXLinux.jpg
-
A distro à qual cada informação se refere
-
Uma contagem, que permite ver – num piscar de olhos – se faltam os dados de alguma distro.
Omiti 3 distros que não estou atualizando (KDE Neon “5”, Slackware, Redcore), e cujos dados não teriam valor. – Só serviriam para confundir.
Pela contagem (embaixo de cada seção) – onde vejo “10 ocorrências”, já sei que não faltaram dados de nenhuma distro.
Em “Fastfetch” (total: 4), sou lembrado de que só consegui instalar em 4 distros (por enquanto): – openSUSE Tumbleweed, Arch, Fedora e Manjaro.
Uso quase que só pacotes dos repositórios oficiais – e um mínimo de pacotes dos repositórios “quase-oficiais” (como AUR, Pakman, RPM Fusion) – de modo que basta 1 comando para atualizar tudo, o mais rápido possível (ou 2 comandos:
pacman
eyay
no Arch;pacman
epamac-cli
no Manjaro).
A contagem também me lembra que só 5 distros estão com Plasma 6 – e nas demais, o comando kinfo
não funciona “fora do DE”. – Ou seja, não funciona nos scripts chamados pelo crontab
– como também não dá muito certo, quando tento executá-lo a partir de algum tty
, fora do DE.
A contagem de “15”, para Frameworks e Qt, reflete a mesma realidade: – Só as 5 distros com Plasma 6 apresentam essa duplicidade de versões – conforme usamos o comando kinfo
ou o comando kf5
. – Tratei de assinalar “kf5” no início das linhas geradas por ele, para evitar confusão.
Sem essa contagem, eu teria de olhar para cada bloco de informações – e “dar tratos à bola”, para lembrar “o que acontece”, em alguns casos.
Ninguém merece.
Aparecem alguns casos “esquisitos”:
- Em 9 distros, o comando
who -b
exibe “system boot” – mas no Fedora exibe “inicialização do sistema”. – Ok, agora sei que alguma coisa no Fedora está “diferente”, e posso marcar essa informação, para lembrar de “padronizá-lo” como as outras distros, quanto tiver um tempinho. – Mas neste momento, precisei adaptar o scriptSummary.sh
, para “ver” (e incluir) as 2 strings:
grep -E "boot|sistema" RAM_* >> Summary.txt
grep -E "boot|sistema" RAM_* | wc --lines >> Summary.txt
- Para listar a versão do Gimp, precisei encontrar uma string capaz de abranger, tanto o texto em inglês de 9 distros, quanto o texto em português do Fedora. – Escolhi “anipula”, que aparece, tanto em “manipulation” quanto em “manipulação”. – Quando digo que essas “crianças” pulam o tempo todo, vocês não acreditam!
grep -E "GNU" RAM_* | grep anipula >> Summary.txt
- No caso do Chrome, precisei incluir uma variação para os dados do Debian, onde uso o Chromium
grep -E "Chrome"\|"Chromium" RAM_* >> Summary.txt
- No “bloco” das versões do
free
/top
(do pacoteprocps
), acabei com uma contagem de “17 informações” – porque em algumas distros, os antigos comandosfree -V
etop -V
já não funcionam. – No PCLinuxOS, por exemplo, o comando para obter a versão étop -h
.
Por isso, não confio em pegar a versão (do
procps
), só pelo comandofree
, ou só pelo comandotop
. – Vai que muda o comando em alguma distro? – Eu poderia acabar com a versão doprocps
só de 9 dessas 10 distros. – Em vez disso, “o que abunda não prejudica”. É melhor ter com sobra, do que faltar.
Enfim, esse script funciona, “hoje” – para essas 10 distros – e pode não funcionar mais amanhã.
E já vi versões anteriores desse script pararem de funcionar – bastando que algum mantenedor ou desenvolvedor (de uma ferramenta, ou de uma distro) achasse que era hora de “quebrar” as pernas de seus usuários. – Sempre, com a melhor das intenções, claro!