Quem sabe um dia se torne realidade (ou já existe?)

[Rommulo_Peixoto]

Olá, amigos!

Quem sabe um dia se torne realidade, ou será que já existe alguma distro ultra-leve com esses recursos?:

• Sem systemd (com runit, openRC ou outro)
• musl em lugar do glibc (se é que pra uso doméstico isso vai ter alguma relevância)
• Wayland em lugar do X11 (não me interpretem mal… não se trata aqui de trocar uma quarentona por duas novinhas de 20 )
• um ambiente ultra leve (quem sabe o LWQt, ou um DWL integrado com o nwg-shell do “Piotr Miller”)
• com um consumo inicial de RAM entre 300 ~ 500 MB.

E ainda:

• appimages compilados sobre musl, pra não dependerem de “binário cross-linux” para vinculá-lo estaticamente (com o tal de “libfuse.so”), pra rodarem em sistemas musl. Será que já existem? Os appimagens que utilizo são compilados sobre glibc, e portanto rodam no Ubuntu, Mint, Debian, Fedora, PopOS!, Arch, Zorin, Deepin e todas as distros mais usadas atualmente. Sei que é possível um usuário mediano ou mesmo iniciante, tentar compilar appimages, mas em musl?!

• flatpaks que se dão com Wayland (li relatos negativos a respeito)

Minha busca não é por algo que rode em máquinas antigas, mas por algo em que sobrem recursos (principalmente RAM) para outras coisas como, por ex., editar vídeos e áudios, jogar, ou abrir várias abas no navegador de internet.

Postei aqui essa questão, pois sei que essa comunidade recebe o apoio de gente gabaritada / expert em Linux, que pode nos brindar com dicas surpreendentes.

O que tentei por minha conta e risco:
Instalei o LXQt 1.3.0 num Void musl e me surpreendi, com seus 10s de boot (em SSD SATA-3), consumo inicial de RAM em meros 320 MB (htop) e Firefox v.118.0 e LibreOffice v.7.6.0 abrindo em menos de 3s. Vou reinstalar, desta vez com Void glibc que roda de boa os appimages que mais utilizo, assim como o xdman (Xtreme Download Manager, um app em java). Quem sabe eu consiga lançar um LWQt nisso…

Apenas por curiosidade, testei o Loc-OS do Nico, baseado em LXDE, e o Bodhi 7.0, ambos com servidor gráfico X11.
Como algo systemd-free e Wayland, testei o Devuan 5.0 daedalus KDE, mas comigo travou demais. A instalação sugeria o init-V mas optei pelo openRC (ou runit, não lembro) e não sei se o Wayland se dá mal com inits menos comuns. Fui então testar o KDE do Artix, mas só iniciava em X11 (talvez por causa do driver nvidia mais recente).

Meu equívoco sobre “peso” vs. desempenho:

Eu pensava que o “peso” de uma distro era inversamente proporcional ao desempenho. Logo o Lubuntu, Puppy, Bodhi, i3, etc, por serem “leves” teriam que ser mais responsivas que as distros “pesadas”. Foi onde me enganei, ao constatar que:

O openSUSE Tumbleweed, tanto com KDE 5.27 quanto Gnome45, me surpreendeu pela velocidade de boot (16s) e abertura dos aplicativos, pareando com o Void (exceto no consumo da RAM). Não é à toa que o openSUSE lidera em vários testes do Diolinux.
O Deepin 20.9 também me surpreendeu, abrindo o LibreOffice tão rápido quanto meu antigo Windows 7 abria o Word XP.

Só que nesse tópico, estou expondo o ideal por uma distro que tenha, ao mesmo tempo, leveza e desempenho, e que sendo sem systemd e com Wayland, tende a iniciar mais rápido e rodar sob um servidor gráfico mais atual (mesmo que ainda em desenvolvimento).

Onde utilizo Linux: notebook LG A560-T, core i7-3630QM (3rd.) / vídeo i915, GPU dedicada GK107M (nvidia GT 640M), chipset Intel HM-77, 16 GB DDR3 (máximo aceito nesse note), SSD 120GB SATA-III pro S.O., e SSD 256GB pra /home, na entrada de DVD usando caddy.

No caso da GPU nvidia, eu ainda não prestei atenção em qual servidor gráfico teria melhor desempenho, nesses cenários:

1. Wayland com nouveau
2. X11 com driver proprietário nvidia
3. Wayland com driver nvidia na versão 470*.

*a atualização mais recente de driver nvidia, no openSUSE TB Gnome45 que eu estava testando, desabilitou o Wayland, e nesse caso tive que desinstalar e retornar ao nouveau).

Pergunto se o desempenho do ffmpeg, seria diferente em cada um desses três cenários, para renderizar vídeos em 1080p, h264, AAC3.

Obs.: Não sei se postei essa questão no lugar certo (“Iniciantes”), ou se poderia ser no “Avançado/Terminal”, pois não encontrei um meio-termo como “Intermediários” nesse fórum.
Mas eu me considero um usuário tão básico quanto os iniciantes no mundo Linux. Quero esclarecer que não mexo ao nível de programação java, pyton, bash, ssh, etc. Apenas domino as configurações e personalizações básicas do sistema, sei particionar o HD e escolher o sistema de arquivos ideal (usando uma ferramenta mais intuitiva, por ex. o Gparted), e sei da existência dos diferentes init systems, glibc, musl e servidores gráficos.
Executo comandos básicos (que mantenho anotados) pra listar, copiar, mover, remover, saber a versão do sistema, drivers de vídeo, checar dispositivos de hardware, etc. e já atribuí alguns “alias” no .bashrc pra economizar digitação.

Ou seja, tenho CNH, sei dirigir de carros a pequenos caminhões, mas não sou mecânico de automóveis

Mesmo assim, pode ser que meu texto acima pareça “grego” pra quem realmente é iniciante por aqui, e tosco pra quem já é avançado…

[Melk]

Se me permite dizer, eu acho que você está exagerando nessa busca pela leveza com desempenho, a não ser que você use um computador construído no ano 2000, o que não parece ser seu caso. Se os recursos do computador foram feitos para serem usados, eu não entendo por que tanto escavamento por leveza se o Void com glibc, o openSUSE e o Deepin funcionaram para você.

@Rommulo_Peixoto

Obs.: Não sei se postei essa questão no lugar certo (“Iniciantes”), ou se poderia ser no “Avançado/Terminal”

Sim, este é um tópico avançado. E não, você não é um usuário iniciante. Você é no mínimo um usuário intermediário para avançado.

[Pio]

Concordo 100% com o que o @Melk disse.

Acrescento que só seria justificado para mim ir em busca de uma distro mais “leve”, se eu estivesse sempre chegando ao ponto de ter que recorrer a toda swap, agora no seu caso você tem 16GB. Não adianta você procurar uma distro que use 300mb, sendo que o grande gastador de memória hoje em dia é o navegador.

Também queria saber qual o problema em estar usando, 5gb, 8gb ou qualquer valor de memória? Tem disponível é para usar.

Sobre o seu pensamento em um dia isso tornar realidade:

Mais leve em termos de memória: 99.99% de chance de não acontecer, pelo simples fato de a memória ser muito barata nos principais países onde são desenvolvido as coisas.

Wayland x x11: Wayland com WM é um porre. Não funciona direito em máquina virtual, tem problemas com placa Nvidia. Por mim migrava tudo para wayland e resolvia estes bugs. Dizem que alguns programas não funcionam muito bem em wayland, o que faz com que tenha resistência a mudança

[mauriciodelima]

Alpine vai funcionar como vc quer pois ele foi concebido com esse propósito. Não li citação sobre ele na sua busca. Pode valer a pena você testá-lo.

[Capezotte]

@Rommulo_Peixoto

• appimages compilados sobre musl […]
• flatpaks que se dão com Wayland

Os Flatpaks são iguais em todas as distribuições e não carregam praticamente nada do sistema (nem mesmo a libc), esse é o grande diferencial desse formato. Quando um Flatpak tem problemas por causa do servidor gráfico em uma distro, ele vai ter em todas (não que eu tenha visto um Flatpak ter problemas desse tipo que não havia no empacotamento nativo).

Agora, AppImages para musl, difícil. As AppImages vem direto do desenvolvedor, e é difícil fazer todos eles concordarem em compilar novamente para um nicho dentro de um nicho. Além disso, não faz sentido compilar AppImages para consumo próprio; no processo, você vai ter que obter as dependências e compilar o programa, e a esse ponto faz mais sentido integrar os resultados ao sistema como pacotes “normais” do que arquivar num AppImage.

@Pio

Também queria saber qual o problema em estar usando, 5gb, 8gb ou qualquer valor de memória? Tem disponível é para usar.

RAM “não usada” é utilizada pelo sistema operacional para agilizar operações do sistema de arquivos. Ter um programa consumindo RAM de modo ineficiente significa operações a mais no armazenamento (o que pesa especialmente no caso de quem tem disco rígido, como eu).

---

Tenho que ressaltar que alguns itens da lista de desejos não são necessariamente os mais leves, mas sim os mais “simples”. Musl e runit em algumas cenário tomam decisões que consomem mais RAM que glibc/systemd, mas que tornam o comportamento do programa mais previsível.

[Natanael.755]

Assim, o único ponto problemático são os AppImage e os Flatpaks. Acho que seu setup com void glibc é o mais promissor possível não dá pra consciliar glibc e musl ao mesmo tempo

@Melk

Se os recursos do computador foram feitos para serem usados, eu não entendo por que tanto escavamento

É simples, dado o modelo atual de sistemas operacionais os apps são conteinerizados na questão de memória, se o sistema usa 2 GB e você tem 8 GB, você na prática tem 6 GB, o problema é quando esse uso NÃO É cache e sim uso real então a resposta pra isso é:

@Pio

Também queria saber qual o problema em estar usando, 5gb, 8gb ou qualquer valor de memória? Tem disponível é para usar.

O problema é usar no lugar errado, legal que o menu de apps abre em 2s ao invés de 3, ou que tem um mapeador que me avisa se tem uma tradução para ucraniano na calculadora mas o quanto isso ajuda eu eu ter a minha tarefa feita? No entanto se eu for editar um vídeo essa RAM certamente vai fazer falta, nem todos podemos dispor mais de 8 GB de RAM, não é o caso dele mas é o caso de milhões de pessoas

[Melk]

@Natanael.755

É simples, dado o modelo atual de sistemas operacionais os apps são conteinerizados na questão de memória, se o sistema usa 2 GB e você tem 8 GB, você na prática tem 6 GB, o problema é quando esse uso NÃO É cache e sim uso real então a resposta pra isso é:

No meu texto ficou bastante claro que esse escavamento dele não faz sentido porque o computador dele não é fraco. Se o computador dele fosse fraco, ok, mas não é o caso.

@Natanael.755

O problema é usar no lugar errado, legal que o menu de apps abre em 2s ao invés de 3, ou que tem um mapeador que me avisa se tem uma tradução para ucraniano na calculadora mas o quanto isso ajuda eu eu ter a minha tarefa feita? No entanto se eu for editar um vídeo essa RAM certamente vai fazer falta, nem todos podemos dispor mais de 8 GB de RAM, não é o caso dele mas é o caso de milhões de pessoas

É por isso que existe uma DE que se adequa a cada tipo de computador. O que não faz sentido é você gastar dinheiro comprando um bom hardware para no final não usá-lo adequadamente, pois dessa forma você não está usando os recursos do computador eficientemente.

Também não faz sentido querer que as DEs modernas parem de avançar por existir gente querendo fazer tarefas pesadas em um hardware que não é adequado para isso.

[Pio]

@Natanael.755

O problema é usar no lugar errado, legal que o menu de apps abre em 2s ao invés de 3, ou que tem um mapeador que me avisa se tem uma tradução para ucraniano na calculadora mas o quanto isso ajuda eu eu ter a minha tarefa feita? No entanto se eu for editar um vídeo essa RAM certamente vai fazer falta, nem todos podemos dispor mais de 8 GB de RAM, não é o caso dele mas é o caso de milhões de pessoas

Para ter um software “perfeito” demanda muito recurso (tempo, mão de obra e dinheiro), e muitas vezes este gasto excessivo não tem um retorno financeiro.

Já estou a um bom tempo usando e é raro encontrar algum software que teve uma atualização com melhorias no consumo de memória, que eu me lembre apenas o Google Chrome implementou isso porque estava sendo muito questionado na internet o seu alto consumo.

Olhando com um olhar comercial, acredito que as prioridades que os desenvolvedores priorizam são:

• Funcionalidades;
• Design
• Responsivo

Já tive pc com pouca memória, sei o problema que é, tinha que me virar com aplicativos ou comandos para limpar a memória ou fechar aplicativos para liberar memória. Mas é como eu disse em um post anterior, o foco é sempre suprir as necessidades do mercado americano e europeu, para nós muitas vezes não tem nem tradução

[mauriciodelima]

Esse negócio de sistema leve baseado apenas em Memória é uma lenda. Um sistema fluido é aquele que carrega consigo uma percepção de uso sem entraves e gargalos de usabilidade prática. Obviamente que quanto mais RAM ele usar melhor será essa experiência.

[romulopb]

@Capezotte

RAM “não usada” é utilizada pelo sistema operacional para agilizar operações do sistema de arquivos. Ter um programa consumindo RAM de modo ineficiente significa operações a mais no armazenamento (o que pesa especialmente no caso de quem tem disco rígido, como eu).

Eu gostaria que alguns gestores de tarefa começassem a fazer mais uso de Pressure Stall Information (PSI) e métricas com base em pressão de uso em vez valores totais.

O jeito como o Mac OS apresenta essa informação é a que eu acho mais fácil para o usuário entender:

E, na prática é isso que se percebe, zero engasgos, apesar deste uso que ele descreve.

[Rommulo_Peixoto]

Olá a todos.

Gratidão por opinarem!

Editei minha resposta no Featherpad, copiando e colando todas as citações.
Perdoem se errei em não responder cada uma separadamente, pois procurei reunir argumentos de diferentes partes desse tópico, na tentativa de consolidar minhas respostas.

@Melk

Se me permite dizer, eu acho que você está exagerando nessa busca pela leveza com desempenho

@Pio

Não adianta você procurar uma distro que use 300mb, sendo que o grande gastador de memória hoje em dia é o navegador.

Minha intenção é que sobre mais RAM pro Firefox, e tbm pra edições de vídeos e áudios.
Estou testando o Chrome, Chromium, Midori, Seamonkey e Falkon. O que comer menos RAM, será meu preferido quando eu precisar abrir várias (pra não dizer muitas) abas. Não sei se o Opera e Edge (e mais algum que não mencionei?) entram nessa lista.

@Melk

você não é um usuário iniciante. Você é no mínimo um usuário intermediário para avançado.

Valeu, Melk!

@Pio

Também queria saber qual o problema em estar usando, 5gb, 8gb ou qualquer valor de memória? Tem disponível é para usar.
(…) Mais leve em termos de memória: 99.99% de chance de não acontecer, pelo simples fato de a memória ser muito barata nos principais países onde são desenvolvido as coisas.

Gosto muito do meu note, e mesmo que pentes de memória sejam baratos, meu note é limitado a 16GB de RAM, o que me parece pouco atualmente.

O openSUSE TB (Gnome 45 e KDE 5.27) e Devuan 5.0 já iniciavam usando até 2,9 GB (com o Franz Messenger, Dropbox e Joplin iniciados com o sistema).

Taí dois argumentos sobre o uso da RAM que achei interessantes, embora eu já esteja concordando com o Melk e Pio no que diz respeito a sistemas mais “leves”:

@Natanael.755

O problema é usar no lugar errado

@Capezotte

Ter um programa consumindo RAM de modo ineficiente significa operações a mais no armazenamento (o que pesa especialmente no caso de quem tem disco rígido, como eu)

O meu é SSD, mas eu nem sabia desse detalhe pra quem usa HDD.

Indo agora pros outros argumentos:

@Melk

É por isso que existe uma DE que se adequa a cada tipo de computador. O que não faz sentido é você gastar dinheiro comprando um bom hardware para no final não usá-lo adequadamente

@Pio

Já estou a um bom tempo usando e é raro encontrar algum software que teve uma atualização com melhorias no consumo de memória, que eu me lembre apenas o Google Chrome implementou isso porque estava sendo muito questionado na internet o seu alto consumo.

Concordo, embora eu ainda goste de ver sobrar RAM, mesmo num hardware potente. Se meu note comportasse 32GB, eu ficaria mais sossegado. Então vou usar mais o Chrome, e evitar multiplicar abas nas minhas pesquisas, pois com Devuan e openSUSE já cheguei a beirar os 15GB, usando Firefox (v.118) com muitas abas carregadas.

@Pio

Wayland x x11: Wayland com WM é um porre. Não funciona direito em máquina virtual, tem problemas com placa Nvidia. Por mim migrava tudo para wayland e resolvia estes bugs. Dizem que alguns programas não funcionam muito bem em wayland, o que faz com que tenha resistência a mudança

Pois é, Pio. Trocar a esposa quarentona por duas novinhas de 20, eis a questão
Quanto aos programas que não funcionam muito bem em wayland, o Xwayland não cumpre bem o seu papel de X11 nesse caso?
Quanto à nvidia, pra mim é célebre esse vídeo do Linus declarando e acenando com o dedo médio: https://www.youtube.com/watch?v=_36yNWw_07g

Quando o openSUSE Tumbleweed com Gnome 45, atualizou os drivers nvidia, o Wayland saiu de cena, e só voltou quando desinstalei os nvidia e o nouveau voltou a atuar.

Já pensei em trocar minha GPU GK107M [GeForce GT 640M] por algo da AMD, mesmo que fosse inferior, mas que rodasse de boa com Wayland. Porém não consegui descobrir se é possível, se a pinagem coincide. Imaginem eu tentar trocar, e explodir a mainboard do meu note LG A560-T! Pois não existe mais esse notebook com tela 3D passiva, e tá difícil achar um usado, mesmo os A530.

@Capezotte

Os Flatpaks são iguais em todas as distribuições e não carregam praticamente nada do sistema (nem mesmo a libc), esse é o grande diferencial desse formato.
(…) Agora, AppImages para musl, difícil. As AppImages vem direto do desenvolvedor, e é difícil fazer todos eles concordarem em compilar novamente para um nicho dentro de um nicho

Valeu por confirmar minha suspeita, acerca dos AppImages.
Sobre os flatpaks, não entendo pq ele baixa vários bancos de dados, cada vez que decido instalar algo mais, após um certo tempo. Dependendo do app, baixa mais de 800Mb.
Quando eu tinha Snap no sistema, o “snapd” tbm baixava um lote de dados, o que era um terror quando eu tinha apenas internet móvel com plano pré pago.

Exemplo:
$ flatpak install flathub com.github.alainm23.planner
ID Ramo Op Remoto Baixar

1. [✓] com.github.alainm23.planner.Locale stable i flathub 2,8 MB / 3,4 MB
2. [—] org.freedesktop.Platform.GL.default 21.08 i flathub 2,1 MB / 129,8 MB
3. org.freedesktop.Platform.VAAPI.Intel 21.08 i flathub < 11,9 MB
4. org.freedesktop.Platform.openh264 2.0 i flathub < 1,5 MB
5. org.gnome.Platform.Locale 42 i flathub < 336,9 MB
6. org.gnome.Platform 42 i flathub < 280,4 MB
7. com.github.alainm23.planner stable i flathub < 28,3 MB

@Natanael.755

Assim, o único ponto problemático são os AppImage e os Flatpaks. Acho que seu setup com void glibc é o mais promissor possível não dá pra consciliar glibc e musl ao mesmo tempo

@Capezotte

Musl e runit em alguns cenários tomam decisões que consomem mais RAM que glibc/systemd, mas que tornam o comportamento do programa mais previsível.

Os argumentos de vcs coincidem com o que pesquisei recentemente, embora existam artimanhas pra compensar a falta do glibc no caso dos Appimages (Support musl-based AppImages · Issue #1112 · AppImage/AppImageKit · GitHub e Reddit - Dive into anything), como também o uso da libfuse. Por isso, optei pelo caminho mais simples: voltar ao glibc, já que também me deixa menos dependente de flatpaks, quando tiver os mesmos apps em Appimage.

Em busca de agarrar a “novinha” Wayland no Void, instalei tbm o KDE*, Wayfire, Weston (e por mera curiosidade tbm o Hikari), resultando num boot mais demorado (uns 18s) e problemas pra desinstalar vários DE’s (que não gostei) e suas libs via OctoXBPS, por conta de “unresolved dependencies”. Vou reinstalar do zero só a base, e em seguida apenas o LXQt + nvidia, e usar isso só pra edição de áudio e vídeo.

*O KDE rodou com Wayland, ao instalar tbm o plasma-wayland-session e egl-wayland, mas em poucos dias resolveu dar uns bugs estranhos, como sumir com meus widgets e com as configurações de monitores e a de redes, sem eu nada mexer.

Vou deixar para apreciar o wayland e o grosso dos aplicativos no all-in-one e ready-to-use BigLinux (recheado de apps e recursos extras, com scripts prontos para facilitar instalações, como por ex. o waydroid), o que me motiva a tê-lo ao lado do Void-glibc.

Embora o openSUSE lidere alguns benchs do diolinux, estou confiante que o Biglinux (glibc/systemd!) tbm seja fluido e responsivo, como marketeiam seus mantenedores. Só é uma pena que o campo de busca/pesquisa do KDE (Alt+space e Alt+F2) não é abrangente como o do Gnome 44/45 que testei. No Gnome, localizo os aplicativos e também praticamente qualquer arquivo pessoal, não apenas os abertos recentemente. E não consigo encontrar algo que torne igual o campo de busca do KDE. Será que tem?

@mauriciodelima

Alpine vai funcionar como vc quer pois ele foi concebido com esse propósito. Não li citação sobre ele na sua busca. Pode valer a pena você testá-lo.

Então, Mauricio, ao ler seu comentário, eu baixei e tentei instalar o Alpine mais recente, mas desisti ao ver que ele iria formatar meu SSD, sem me permitir escolher manualmente as partições (pelo menos no seu processo padrão de instalação). Vou testá-lo quando tiver mais um HD ou SSD, totalmente vazio e exclusivo pra descer a marreta na bancada do Iberê Tenório .

@mauriciodelima

Esse negócio de sistema leve baseado apenas em Memória é uma lenda. Um sistema fluido é aquele que carrega consigo uma percepção de uso sem entraves e gargalos de usabilidade prática. Obviamente que quanto mais RAM ele usar melhor será essa experiência.

Então não estou enganado, onde citei meu equívoco sobre “peso” vs. desempenho. Eu me supreendi com o Deepin e o openSUSE, mesmo com Gnome 45.
Veja a situação: eu de Void-glibc com LXQt, sem os drivers nvidia: meu VLC já tá dando engasgos com vídeos 720p ou acima, quando salto trechos maiores, principalmente retrocedendo. Quando eu usava o Mint MATE 18.04, o VLC pixelizava a ponto da tela virar um borrão acinzentado, mesmo com drivers nvidia 100% ok. Aí abro o mesmo vídeo num app mais leve como por ex. o mplayer, e o problema diminui ou até acaba.

@romulopb

Eu gostaria que alguns gestores de tarefa começassem a fazer mais uso de Pressure Stall Information (PSI) e métricas com base em pressão de uso em vez valores totais.

O jeito como o Mac OS apresenta essa informação é a que eu acho mais fácil para o usuário entender

Fala meu xará! Eu por exemplo, só sei consultar o status da RAM pelo “free -h”, htop, monitor do sistema e stacer. E cada um diz uma coisa…

Alguém sabe se tem pra Linux algum app ou comando capaz de apresentar as métricas de uso da RAM, de forma semelhante ao do OS-X, como citado pelo meu xará?

Quando vc comentou “E, na prática é isso que se percebe, zero engasgos, apesar deste uso que ele descreve.” vc está se referindo ao OS-X? Nos meus tempos pré-históricos das famigeradas telas azuis do meu Win95, eu ansiava por um Mac, mas não tinha din din pra isso.
E se for verdade que já vi alguém se queixar do OS-X, definitivamente não me recordo!

Engasgos é o que não desejo no VLC, e menos ainda num KDEnlive ou Shotcut… e é nesse quesito que continuo curioso pra saber se alguém de vcs já teve experiência em editar e renderizar vídeos num X11 com nvidia, e num Wayland com nouveau, no mesmo sistema e hardware. Ou será que isso independe de se usar a GPU dedicada com driver proprietário? Já vi propaganda de placas de vídeo nvidia custando muito além de 80 mil reais, perfeitas pra uso em estúdios de cinema e empresas de engenharia civil e mecânica… claro que não é minha necessidade (rs), pois o KDEnlive e Shotcut rodam de boa, até com a HD Graphics 4000 do próprio i7-3630QM .

[Capezotte]

@Rommulo_Peixoto

Sobre os flatpaks, não entendo pq ele baixa vários bancos de dados, cada vez que decido instalar algo mais, após um certo tempo. Dependendo do app, baixa mais de 800Mb.

Flatpaks podem puxar outros Flatpaks como dependência.

Em especial, esses que contém .Platform e .Runtime no nome são várias bibliotecas comuns juntas e têm como intenção ser a base dos demais pacotes. Teoricamente, só tem esse “pico” de tamanho de download quando você instala seu primeiro Flatpak ou uma vez a cada 6 meses, que é quando os “platform” são atualizados.

Mesmo assim, na minha experiência, a deduplicação e as outras técnicas de conservação de espaço do OSTree só compensam o tamanho enorme dos runtimes individuais se você tiver vários e vários aplicativos como Flatpak; numa ocasião que eu tinha 3 Flatpak, mas que cada um puxava uma versão diferente do runtime “fundamental” (org.freedesktop.Platform), foi uma economia de mais de 50% mudar para os AppImages correspondentes, mesmo estando com 3 cópias do GTK, 3 cópias do glib, etc.

@Rommulo_Peixoto

Alguém sabe se tem pra Linux algum app ou comando capaz de apresentar as métricas de uso da RAM, de forma semelhante ao do OS-X, como citado pelo meu xará?

Nos kernels Linux lançados nos últimos 4 anos, essa informação tem disponível no arquivo /proc/pressure/memory. Ainda não sei de nenhum monitor do sistema que o exiba num formato bonitinho como o no macOS.

---

@Rommulo_Peixoto

já cheguei a beirar os 15GB,

Quantas abas é isso? Tenho quase 20 abas abertas no Firefox e nem assim consigo chegar as mais de 70% dos meus 8GB.

[Rommulo_Peixoto]

@Capezotte

Quantas abas é isso? Tenho quase 20 abas abertas no Firefox e nem assim consigo chegar as mais de 70% dos meus 8GB.

Parece que fujo ao ditado “beba com moderação”. Quando me empolgo com vários assuntos ao mesmo tempo, por distração saio abrindo várias janelas e várias abas. Atualmente abro links em novas abas, mas evito carregar todas ao mesmo tempo: não clico logo em todas as novas abas, clico em umas 4 ou 5 pra ler ou assistir, e fecho antes de clicar nas próximas.

[Rommulo_Peixoto]

@Capezotte

Ainda não sei de nenhum monitor do sistema que o exiba num formato bonitinho como o no macOS.

Vc poderia citar algum monitor, mesmo que tenha uma apresentação menos estilosa que do macOS? Sendo com base no PSI (correto?), eu fico satisfeito.

Nesse vídeo do Diolinux, entendi como o Linux gerencia a RAM e o cache: https://www.youtube.com/watch?v=BxrXzcB90Mg e o comando utilizado por ele foi o free -m

[Rommulo_Peixoto]

@Capezotte

numa ocasião que eu tinha 3 Flatpak, mas que cada um puxava uma versão diferente do runtime “fundamental” (org.freedesktop.Platform), foi uma economia de mais de 50% mudar para os AppImages correspondentes

Pois é, amigo. Eu curto Appimages. Evitam que eu fique reinstalando os apps correspondentes e suas dependências, cada vez que migro para uma nova distro. E é onde uma posterior desinstalação dos apps pode deixar rastros como pacotes órfãos. Quando sei usar o argumento “purge”, a desinstalação torna-se mais certeira, correto? Já os Appimages basta carregar e utilizar…

Quanto aos flats e snaps, tenho preferência (gosto pessoal mesmo) pelos instaladores nativos dos ppa’s, ou mesmo baixar e instalar .deb, .rpm, .run e .sh. Os appimages e .jar são meus prediletos, e só por último procuro os flatpaks e snaps.

Por ex., o Planner (da Todoist) e o Planify (organizadores de compromissos) eu só encontrei em flatpak. Concordo que acaba sendo uma facilidade pros desenvolvedores, mas eu gostaria de consegui-los também em Appimage.

[Melk]

@Rommulo_Peixoto

E é onde uma posterior desinstalação dos apps pode deixar rastros como pacotes órfãos

Minha estratégia é a seguinte:

flatpak remove --delete-data NOME-DO-PROGRAMA
flatpak remove --unused

Desse jeito eu levo embora os flatpaks, os arquivos de configuração e as dependências desnecessárias.

Já para .debs eu gosto de dar o comando

sudo apt purge --auto-remove NOME-DO-PROGRAMA

Infelizmente o snap te permite, no máximo, remover o programa junto aos arquivos de configuração, deixando as dependências para trás. Isso até tem me causado dores de cabeça no gerenciamento dos snaps.
sudo snap remove --purge NOME-DO-PROGRAMA

Resumindo, quase todos os gerenciadores de pacotes te permitem remover os rastros dos programas desinstalados.

[romulopb]

@Rommulo_Peixoto

Quando vc comentou “E, na prática é isso que se percebe, zero engasgos, apesar deste uso que ele descreve.” vc está se referindo ao OS-X? Nos meus tempos pré-históricos das famigeradas telas azuis do meu Win95, eu ansiava por um Mac, mas não tinha din din pra isso.

Sim, no Mac, mas a questão é que isso não é uma coisa só do Mac OS, é preciso entender uma coisa… Métricas de pressão avaliam de fato com quanta dificuldade o sistema está. Em particular a PSI é uma métrica que avalia quanto % do tempo as tarefas rodando no Linux ficam “empacadas” (paradas sem poder rodar) esperando pela liberação de algum recurso (RAM, CPU, I/O).

Estas métricas são boas porque não existe mistério… Valores altos são ruins e ponto final, enquanto outras métricas, exigem uma interpretação em um contexto maior.

Por exemplo, só olhando para aqueles 14 GB de 16 GB, muita gente pensa: “meu Deus, não tem mais RAM! Deve estar no sufoco!”, sendo que eu sei que o sistema tem folego de sobra para abrir até mais uma VM naquele contexto ali, sem nenhum engasgo.

[Rommulo_Peixoto]

@Melk

flatpak remove --delete-data NOME-DO-PROGRAMA
flatpak remove --unused
sudo apt purge --auto-remove NOME-DO-PROGRAMA
sudo snap remove --purge NOME-DO-PROGRAMA

Acabo de tomar nota dessas suas dicas, em minha coletânea de comandos essenciais!

[Rommulo_Peixoto]

@romulopb

Por exemplo, só olhando para aqueles 14 GB de 16 GB, muita gente pensa: “meu Deus, não tem mais RAM! Deve estar no sufoco!”, sendo que eu sei que o sistema tem folego de sobra para abrir até mais uma VM naquele contexto ali, sem nenhum engasgo.

No vídeo do Diolinux que mencionei ao Capezotte, o Dionatan abriu vários apps com a RAM quase lotada, e não houve nenhum travamento pq o sistema lançava os excessos no cache.

Só não sei pq não tive a mesma sorte: quando meus 8 GB de RAM lotavam (antes de eu upgradar pra 16GB), o Void LXQt congelava geral e o LED do HDD ficava aceso direto… aí eu perdia a paciência e pressionava o Power por 4s.

[romulopb]

@Rommulo_Peixoto

Só não sei pq não tive a mesma sorte: quando meus 8 GB de RAM lotavam (antes de eu upgradar pra 16GB), o Void LXQt congelava geral e o LED do HDD ficava aceso direto… aí eu perdia a paciência e pressionava o Power por 4s.

PSI é o primeiro passo para saber se tem algo indo mal, no seu caso fica óbvio pelo travamento. O segundo é investigar o OS como um todo para responder as perguntas : quem, quando, porque, etc…

Em casos assim colocamos algum script para ficarem registrando a cada x segundos (um loop) algumas informações, via ps e iotop, ou copiando e salvando dados em arquivos como:

• /proc/io_status
• /proc/diskstats
• /proc/slabinfo
• /proc/meminfo

Algumas vezes também são configurações que “futricamos”, como por exemplo /etc/sysctl.conf, existem muitos parametros de kernel que comportam o comportamento do sistema de paginação de memória.

Mas também, as vezes o motivo é óbvio, digamos que você quer criar uma imagem de 250.000x250.000 pixels no Krita, seria necessário algo como:

(250000x250000x16bit(modo mais básico)/8(bytes)/1024(KB)/1024(MB)/1024(GB) = + de 100 GB de RAM.

E ai é mais uma questão de conhecer os limites da ferramenta que está usando.