Maluquices de um dualbooter / multibooter

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. :sweat_smile:

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. :grin:

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 o inxi ou o htop (+ 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. :weary:

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: :scream:

# 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 e yay no Arch; pacman e pamac-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 script Summary.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 pacote procps), acabei com uma contagem de “17 informações” – porque em algumas distros, os antigos comandos free -V e top -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 comando free, ou só pelo comando top. – Vai que muda o comando em alguma distro? – Eu poderia acabar com a versão do procps 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!

2 curtidas

Por necessidade ou conveniência?
Fica executando algum processo durante a noite?

O Sleep cumpriu bem a função dele.

1 curtida

É mais por “comodidade”, mesmo.

Quando dá sono, paro o trabalho e vou dormir. – No outro dia, basta apertar 1 tecla, e continuar, do ponto onde parei – com os aplicativos abertos, os textos posicionados, imagens, planilha etc.

De repente, acordo às 2:00 da madrugada, e continuo o trabalho. – Quando o sono volta, torno a interromper o trabalho.

Uma vez, experimentei a Hibernação (acho que foi isso), há muitos anos. – Se não me engano, era mais demorado, pois precisa salvar / recuperar tudo, do SSD.

1 curtida

Deveria haver algo como “salvar a sessão” e que, ao ligar novamente, permitisse que os aplicativos fossem abertos na mesma disposição e posição (textos, p. ex.).

Pra ser sincero, nunca pesquisei se há esse recurso. Seria bem interessante e útil.
No seu caso, o Sleep já ajudou bem.

1 curtida

Se não me engano dá pra fazer isso no xfce, mas eu nunca testei o recurso na prática.

2 curtidas

Existe, sim!

Experimentei muito, esse recurso, acho que em 2016 – mas notei que:

  • Só reabria corretamente os aplicativos Qt – Dolphin, Kate, KWrite, Gwenview etc.

  • Não funcionava para aplicativos GTK – Chromium, Gimp etc.

1 curtida

O Gnome já teve essa função, também, há muitos anos.

Teria que experimentar se, agora, está funcionando bem no KDE.
O Gnome não tem essa função disponível para selecionar.
Parece que, usando o Dconf, é possível.
Mas, não é como sugeri, acima. Não se pode desligar o computador.

1 curtida