Translate

quarta-feira, 30 de maio de 2018

Aprendendo a lidar com IceWM no antiX

Aprendendo a lidar com IceWM no antiX

O antiX é uma implementação do Debian sem SystemD, — e sem KDE Plasma ou qualquer outro “desktop environment” (DE), por padrão. — Vem apenas com gerenciadores de janela (window manager, ou “WM”).

Ao longo de 3 dias de uso, — com vários Restart, — apresentou consumo inicial de Memória RAM sempre em torno de apenas 137 MiB ~ 139 MiB, em sessões Rox-IceWM.

  • Depois de instalar o KDE, no 4º dia, as sessões Rox-IceWM passaram a iniciar usando cerca de 155 MiB.

Isso o torna ideal para máquinas antigas ou de poucos recursos, — bem como para quem dispensa comodidades.

Sessões oferecidas na instalação-padrão do antiX

O antiX padrão oferece uma série de combinações em torno dos gerenciadores de janela Fluxbox, IceWM, JWM, — e na falta de decisão em contrário, carregou sempre “Rox-IceWM”.

Até então, minha única experiência com IceWM se limitara a um susto momentâneo, após uma falha de atualização no Mageia 6 sta2, — e nem cheguei a ver o Rox Filer. — Tentar trabalhar com essa combinação, desconhecida, se mostrou uma barreira à produtividade para quem, há mais de 10 anos, só usa KDE.

O que se segue, portanto, não é um “guia”, — mas apenas um registro de “primeiros passos” no aprendizado, — e de vários improvisos, ao longo de 3 dias de trabalho difícil.

Índice


  • Rox Filer
  • Geany e configurações em arquivos de texto
  • Midnight-Commander e /etc/fstab
  • Conky
  • “Slot 10”
  • Quadro comparativo
  • KDE Plasma
  • antiX vs. MX Linux
  • Wallpaper

Referências



Rox Filer


Configuração do Rox Filer para não redimensionar ao navegar pelas pastas

Simplesmente não pude me acostumar a um Rox Filer, — que muda de tamanho e formato, de modo brusco, o tempo todo, — a cada vez que você navega por pastas com maior ou menor número de arquivos.

Tiling window manager

Felizmente, ele pode ser amansado, em suas Opções, — “Nunca redimensionar automaticamente”.

Mesmo assim, fizeram falta inúmeros recursos (ou comodidades), — provavelmente por falta de aprendizado, — pois é descrito como “poderoso”.

Acabei instalando o Nemo, — que também não foi muito prático, pois veio apenas com o mínimo, — e além disso, vive fechando sem aviso, por qualquer motivo.

  • No 4º dia, a instalação do KDE trouxe o Dolphin, — que não apresentou esse problema, mesmo em sessão Rox-IceWM.

Geany e configurações em arquivos de texto


Edição de arquivos de configuração no Geany

Boa parte das Configurações oferecidas remetem diretamente à edição de arquivos pelo Geany, — que por sinal, se mostrou uma excelente ferramenta.

Se você fecha o Geany com vários documentos abertos em abas, — digamos: ~/.conkyrc, ~/.icewm/menu e Notas.txt, — eles são carregados automaticamente, ao reabri-lo.

Isso pode ser muito melhor do que apenas “lembrar” arquivos recentes, — a serem abertos manualmente, um por um.

  • Depois desse dia, configurei o Kate para também reabrir a última sessão, nas demais distros.

Configuração de teclas de atalho em ~/.icewm/keys

A diferença entre os 138 MiB iniciais do antiX Rox-IceWM, — e os 331 MiB iniciais do Devuan 2 Beta KDE, por exemplo, — se evidencia quando você tenta fazer coisas simples, como criar ou modificar uma tecla de Atalho.

Ao invés de 2 ou 3 cliques “intuitivos”, é preciso editar arquivos de configuração, — não sem antes pesquisar e aprender, — o que é bom, mas também tem hora.

Para acionar o Gnome-screenshot pela tecla PrtScn, por exemplo, “basta” criar esse Atalho no arquivo ~/.icewm/keys, — e dizer o que pretende que ele faça.

Desativação de itens do Painel (Taskbar)

Para retirar do Painel 2 itens desnecessários, “bastou” editar ~/.icewm/preferences, — e substituir “1” por “0” nas respectivas linhas.

Cópia de itens do Menu de Aplicativos para o Painel (Toolbar)

Para colocar alguns Lançadores (Launcher) no Painel, bastou copiá-los de ~/.icewm/menu-applications.

Cópia de itens do Menu de Aplicativos para a área principal do Menu

Outros Lançadores, — de uso mais frequente, — foram copiados para o primeiro nível do Menu.

  • Obs.: - Em outras distros, costumo chamar Gimp a partir do Gwenview, — e pyRenamer a partir das pastas no Dolphin, — mas ainda falta um longo caminho, até aprender a “construir” essa associação de arquivos no Rox-IceWM.

Midnight-Commander e /etc/fstab


Configuração do Midnight-Commander para usar seu editor interno mcedit, em vez do nano

Na falta de um aplicativo conhecido para automatizar a edição do /etc/fstab, optei por resolver o assunto rapidamente, usando o Midnight Commander em modo Root, — mas primeiro, queria substituir o editor Nano por seu editor interno (mcedit).

Tal como já foi notado em outras distros, as Configurações do Midnight Commander escondem esta opção debaixo de um nome, — “Conteúdo:” [sic! com 2 pontos], — sem qualquer relação com o assunto… como se fosse um título para as demais opções, logo abaixo.

Onde se lê "Conteúdo:", leia-se "Usar o editor interno" (mcedit).

Cópia da montagem de partições dos HDDs do /etc/fstab do Devuan

Uma vez aberto o /etc/fstab pelo mcedit, bastou colar (Ctrl-Shift-V) uma seção inteira trazida do Devuan, — onde essa parte foi gerada automaticamente pelo Gerenciador de Discos (Disk-Manager).

Com isso, foi poupado muito tempo, trabalho, — e erros de leitura, memória, digitação, — evitando lidar com inúmeros identificadores UUID, pontos de montagem repetitivos etc.

Trata-se das partições dos HDDs internos, — cuja montagem, no Devuan (e no Debian), também deixei por conta dos respectivos /etc/fstab, — pois nessas distros, só as partições do SSD externo (USB) são montadas automaticamente pelo uDev.

O bloco de texto foi copiado do arquivo do Devuan, — também instalado no SSD externo, — pois o do Debian exigiria correções manuais em alguns detalhes (sda3, sda7).

  • Ver “Slot 10” (adiante).

No detalhe da imagem (acima), o motivo de usar o mcedit: — Não era possível gravar /etc/fstab pelo Geany, — pelo menos, até descobrir como abri-lo com privilégios de Administrador ou de Super-usuário.

Criação dos pontos de montagem para as partições dos HDDs em /etc/fstab

A segunda parte do trabalho que seria realizado pelo Disk-Manager, — criar os pontos de montagem, — foi feita manualmente.

Pontos de montagem automática das partições adicionais

Não foi necessária qualquer preocupação com propriedades e permissões, — cada ponto de montagem assume as das respectivas partições.

Conky


Edição do ~/.conkyrc com itens do backup do antigo Rosa Desktop

Aproveitei o arquivo ~/.conkyrc, que já veio com o antiX.

Bastou editá-lo, — trazendo blocos de texto de seu equivalente no antigo Rosa Desktop, — que tinha sido instalado na mesma partição.

  • Ver “Slot 10” (adiante).

Configuração do acesso ao 3º nível do Teclado

Habilitar o acesso ao 3º nível do Teclado foi a tarefa mais simples de todas. — Bastou selecionar Left-Win, que já estou acostumado a usar nas outras distros.

Habilitar o NumLock, não está sendo tão simples, — embora oferecido pela mesma ferramenta, — talvez porque só lembrei disso depois que já tinha feito a “mistura” do KDE.

Uma triste experiência anterior, — Debian com vários ambientes gráficos (DEs), — já tinha mostrado quantos conflitos de configurações essa mistura pode causar.

“Slot 10”


Particionamento dos HDDs / SSD em “slots” para instalação de até 12 distros Linux

As referências ao particionamento, — ao tratar do /etc/fstab e do ~/.conkyrc, — entendem-se pela padronização adotada, com “slots” para instalação de até 12 distros Linux, cada uma com Home e Swap próprios.

  • Na maioria das distros, a montagem automática das partições “adicionais” é feita pelo próprio KDE (System settings), — que usa udisks / polkit.
  • No Debian, no Devuan e no antiX, a montagem automática é feita pelo /etc/fstab, para as partições “adicionais” situadas nos 3 HDDs, — e pelo uDev, para as partições “adicionais” situadas no SSD externo. — Por isso, esta seção do ~/.conkyrc é idêntica no Devuan e no antiX (que estão no SSD externo), porém um pouco diferente no Debian (que está em um HDD interno).

Quadro comparativo


Comparativo das distros instaladas em 10 Jun. 2018

O comparativo omite as características relacionadas ao KDE, — inclusive o espaço ocupado em disco, na partição de sistema, que aumentou após a mistura de ambientes; — e o tempo de Boot, que no momento é prejudicado pelo Login manual.

KDE Plasma


antiX em sessão KDE, — ainda bastante capenga

Embora seja possível instalar o KDE, os resultados foram pífios.

Dias depois, o antiX foi substituído pelo MX Linux, — onde a experiência de instalar o KDE deu resultados melhores.

antiX vs. MX Linux


Instalador gráfico do MX Linux deixa de atualizar a tela, tão logo se confirma a seleção das partições

A intenção inicial era instalar o MX Linux, — porém seu instalador apresentou um bug ainda sem solução para alguns hardwares: — Congela logo no primeiro passo: a escolha das partições.

O antiX usa exatamente o “mesmo” instalador, — que, neste caso, não apresentou esse problema.

2018-06-11 - Instalado o MX Linux, — nas mesmas partições, — encerrando assim a experiência com o antiX.


Wallpaper


Imagem de Denys Mota em São Luís do Maranhão, 2015

Foto da Escadaria da Rua do Giz, em São Luís (Maranhão, 2015), por Denys Mota, — sem tratamento, — cortada automaticamente nas laterais, ao aplicar como Wallpaper.

_______________________
Publicado em 30 Mai. 2018, no antiX, e desenvolvido a partir de 31 Mai. 2018, no KDE Neon.

— … ≠ • ≠ … —

Without-SystemD



    Debian's


    Postado por Mboaba às quarta-feira, maio 30, 2018 7 comentários
    Marcadores: , ,

    quinta-feira, 17 de maio de 2018

    Devuan 2 Beta KDE - Desastre e recuperação

    Início do desastre com o KDE Plasma (testing) no Devuan 2 Beta

    21 Abr. 2018 - O desastre com o KDE Plasma do Devuan 2 Beta foi causado, provavelmente, por alguma alteração na teia de dependências, — envolvendo dezenas de pacotes do PIM & Akonadi removidos 2 meses antes, — e de certo modo acabou funcionando como um “freio de arrumação”.

    • Ver “Release Candidate e mudança de status do KDE” (adiante)

    Em resumo, as atualizações propostas pelo Synaptic implicavam em remover o próprio Synaptic e alguns pacotes críticos do KDE, Polkit, gerenciador de Rede etc.

    Além de não “entender” muita coisa do GNU / Linux, eu devia estar com a atenção meio dividida entre outras questões, — Cooler entupido, Grub doido, Manjaro chucro, — mas, por mais que examine hoje aquele dilema, continuo sem imaginar o que poderia fazer naquela situação.

    O Synaptic resistiu bravamente, até o final, — registrou até o log de sua própria remoção, — mas esperar que, em seguida, ainda abrisse o Histórico, para exibir a façanha… Bom, aí talvez já fosse querer demais.

    Índice


    • Sem rede
    • Demolição do KDE em capítulos
    • Existe vida sem KDE
    • Recuperação do KDE
    • De volta para o futuro
    • Release Candidate e mudança de status do KDE
    • Outras configurações
    • PIM & uso inicial de RAM
    • Remoção do Akonadi
    • O caso do Debian testing

    Referências



    Sem rede


    Falha de Rede ao tentar reinstalar o Synaptic

    12:55 - Ao tentar apt install synaptic, nenhum dos 4 pacotes previstos pôde ser obtido. — O mais provável é que fosse falha de Rede, afinal tinha acabado de remover network-manager, — mas se este fosse o caso, como reinstalar esse pacote… sem Rede?

    Tampouco podia descartar a possibilidade de falha nos repositórios, — embora ainda não saiba como direcionar para um ou outro espelho (Mirror). — De qualquer modo, parece que são poucos, todos na Europa, exceto 1 no Chile (e nenhum no Brasil, por enquanto).

    A experiência dos últimos 3 meses já tinha mostrado que, às vezes, a velocidade de acesso aos repositórios cai a níveis exasperantes. Várias vezes, também, um mero apt update (Reload, no Synaptic) já terminou em erro, — sem que houvesse qualquer falha de Rede (navegação normal), — e bastava tentar de novo algumas horas depois, para encontrar tudo normalizado.

    Mas dessa vez, mesmo sem alcançar nenhum repositório, o apt install deixou um aviso alarmante, — uma tonelada de pacotes (praticamente todo o KDE Plasma, além do LibreOffice e mais alguma coisa!) “já não são necessários”, — “Utilize apt autoremove para os remover”.

    LibreOffice “auto-removível” desde Fevereiro

    A rigor, isso nem era novidade, — desde a remoção do PIM & Akonadi, em Fevereiro, o Synaptic já listava 208 pacotes “Removíveis” (incluindo todo o LibreOffice), que nem por isso deixavam de receber atualizações, — mas a apresentação desse dilema, agora, soou como um ultimato: não dava mais para ignorar.

    Só que, agora, tratava-se de remover 300 pacotes, — mas isso ficou para a semana seguinte.

    Em todo caso, minutos depois o Chromium confirmou que, de fato, estava sem Rede.

    Demolição do KDE em capítulos


    Colapso do KDE Plasma e Reboot pelo tty3

    Em seguida, o Menu deixou de responder, — provavelmente, o KDE só estava funcionando por inércia (pré-carregado), e cada iniciativa que dependesse de um pacote removido, ia demolindo o ambiente, pedaço por pedaço.

    Feito o Reboot, — por comando Root a partir do tty3, — o Devuan carregou com o Painel desmantelado, Menu inoperante; e o Conky em fundo preto, confirmando zero tráfego de Rede.

    Nestas circunstâncias, as fotos de celular são muito pouco úteis, — quase todas mal focadas (letras miúdas), — exceto para datar os acontecimentos.

    Não houve mais Capturas de tela, — mas não há registro de que tenha tentado fazê-las, — nem de que a tecla PrtScn ou o gnome-screenshot se recusassem a funcionar.

    Existe vida sem KDE


    Atualização do Grub, — com KDE desconchavado

    22 Abr. 2018 - No dia seguinte, o Devuan voltou a ser carregado, — Painel desconjuntado, Menu fora de combate, Conky sobre fundo preto, — e não há registro de como consegui abrir Dolphin, Kate, Konsole (talvez pelos lançadores no Painel, que acabou se arrumando; mas o Menu não ressuscitou).

    Em boa hora, acionei o gnome-screenshot pela tecla de atalho PrtScn, — e funcionou, — de modo que é possível conferir os indicadores desta sessão, com nitidez.

    O objetivo, nesse dia, era apenas disparar um update-grub, — com os_prober previamente desabilitado (a partir do openSUSE), — o que reduziu o arquivo /boot/grub/grub.cfg de 552,2 KiB para 9,2 KiB, em 15 segundos.

    O conserto geral do Grub era urgente, — e em certa medida, pré-requisito para poder cuidar do Devuan.

    Recuperação do KDE


    Confusão ao tentar um comando no Modo de recuperação (Recovery mode)

    27 Abr. 2018 - Só na outra semana, finalmente foi carregado o Modo de recuperação (Recovery Mode), — que está longe de oferecer a mesma moleza do Ubuntu & derivados.

    Após entrar com a Senha (para Manutenção), nem cheguei a completar o comando pretendido, — que pretendia ser apt-get install -f, — e o sistema já começou (ou continuou) a dar retorno de outras coisas, sem qualquer relação.

    Removendo tudo que o apt queria, — basicamente, todo o KDE Plasma

    Mas o histórico não deixa dúvida, — de fato apenas tentei atualizar o apt (sem rede!), — e já mandei remover aquilo tudo, que vinha sendo proposto, para deixar de repetir sempre a mesma ladainha, a cada passo que se tentava dar:

    # apt-get install
    # apt update
    # apt autoremove
    # reboot

    Ativando e testando a Rede, para rodar o Tasksel

    Embora tenha pesquisado e anotado vários comandos para configuração de Rede, apenas um funcionou, — e foi mais do que suficiente, para restabelecer a conexão.

    Depois, bastou testar, — e rodar o Tasksel em seguida:

    # dhclient eth0
    # ping 8.8.8.8
    # tasksel

    Re-instalando o KDE pelo Tasksel

    No Tasksel, foi selecionado apenas o KDE, — e para minha surpresa trouxe de volta o LibreOffice, — que, desde então, nunca mais o apt / Synaptic classificou como “Removível”… até remover o Akonadi outra vez.

    Velocidade de Rede inferior à “conexão discada” da antiguidade

    Infelizmente, o processo todo demorou mais de 1h10min (16:52 ~ 18:05), — com o Conky (tty7) indicando download em velocidade inferior à da Idade da Pedra.

    Devuan 2 Beta com KDE reinstalado e (quase) todas as configurações intactas, — após 1h28min

    Ainda no tty7, apenas foi encerrada a sessão (por Ctrl-Alt-Del + Enter), — feito novo Login, — e a nova sessão já exibiu o KDE inteiro, zerado, com (quase) tudo configurado como antes.

    De volta para o futuro


    Ao contrário do padrão original, o 1º usuário já não era Administrador

    Foi necessário tornar a configurar alguns detalhes:

    • Reinstalar o Synaptic (pelo Apper) - download entre 28 ~ 43 KiB/s
    • Passar novamente o Compositor de OpenGL 2.0 para XRender
    • Desabilitar novamente a Carteira do KDE (KWallet)
    • Restabelecer o Usuário principal como Administrador (sudo)

    Synaptic só abria por comando Root, desde Fevereiro

    Cabe lembrar que desde a instalação do Devuan 2 Beta, em Fevereiro, o Synaptic jamais abriu pelo Menu, — simplesmente abortava, — e tinha de ser chamado por comando Root.

    Agora, basta clicar no Menu, — entrar com a senha Root, — e abre normalmente.

    Desabilitando a Carteira de senhas do KDE (KWallet)

    Mas outras coisas também melhoraram, — como se várias implementações se tivessem alterado, de Fevereiro para cá, — e o “acidente de percurso” tenha funcionado como um “freio de arrumação”.

    Desta vez, por exemplo, desabilitar o KWallet funcionou sem problemas.

    Release Candidate e mudança de status do KDE


    No Tasksel, KDE, Cinnamon e LXQt deixaram de ser apresentados como “Testing”

    De fato, houve uma atualização do Tasksel (+data) em 16 Abril, — uma semana antes do desastre, — e é possível que aí tenham chegado algumas mudanças nas dependências dos pacotes, com as quais a situação anterior talvez fosse incompatível.

    Aliás, parece ter havido alguma aceleração nas mudanças do Tasksel: — Uma única atualização, de Fevereiro até Abril, — e agora três, em cerca de 30 dias:

    Apr 16 - tasksel (3.39+devuan1.6.1) to 3.39+devuan1.7
    May 5  - tasksel (3.39+devuan1.7) to 3.39+devuan1.8
    May 17 - tasksel (3.39+devuan1.8) to 3.39+devuan1.9

    Em algum momento, — infelizmente, não percebido e não-documentado, — o Tasksel deixou de exibir a advertência de “Testing” para o KDE, o Cinnamon e o LXQt.

    Embora o desastre tenha ocorrido em 21 de Abril, — possivelmente em decorrência de alterações trazidas pela atualização de 16 de Abril, — parece muito provável que já prenunciassem o RC oficialmente divulgado em 9 de Maio.

    O anúncio frisa, especificamente, que o instalador “agora oferece uma variedade mais ampla de ambientes, incluindo XFCE, KDE, MATE, Cinnamon, LXQt”:

    Devuan 2.0 ASCII Release Candidate
    2018-05-09 22:26:51
    We are happy to announce that the Devuan 2.0 ASCII Release Candidate is now available thanks to the support, feedback, and collaboration of the Devuan community. Devuan 2.0 ASCII Stable will be following soon.

    The Devuan 2.0 ASCII RC installer now offers a wider variety of Desktop Environments including XFCE, KDE, MATE, Cinnamon, LXQT (with others available post-install).  In addition, there are options for "Console productivity" with hundreds of CLI and TUI utils, as well as a minimal base system ideal for servers.

    When installing from ISO, the expert install option offers a choice of SysVinit and OpenRC. Official ready-to-use Devuan 2.0 ASCII RC images are available for dozens of ARM boards and SOCs, including Raspberry Pi, BeagleBone, OrangePi, BananaPi, OLinuXino, Cubieboard, Nokia N900, and several Chromebooks, as well as for Virtualbox/QEMU/Vagrant.

    Outras configurações


    Desde a instalação do Devuan 2 Beta (Fevereiro), ficaram faltando 2 configurações, — que já são hábito antigo, nas demais distros instaladas, — mas ainda não havia aplicado no Devuan:

    • Remover PackageKit, — que verifica os repositórios, em horas inoportunas
    • Remover Unattended-upgrades, — que atualiza (alguns) pacotes sem pedir licença

    Desinstalar PackageKit implicou na remoção do Plasma-Discover e do Apper. — Até gosto do Apper (embora prefira Synaptic), — mas evito sistematicamente o Plasma-Discover.

    Por fim, faltava refazer:

    • Remover PIM & Akonadi (este último voltou a carregar 16 processos)

    PIM & uso inicial de RAM


    Processos Akonadi jamais usados, — carregados automaticamente a cada sessão

    A reinstalação do conjunto PIM & Akonadi (completo) voltou a elevar o consumo inicial de Memória RAM, — com nada menos que 17 processos Akonadi rodando sem necessidade.

    Antes do desastre:

    2018-02-17 - 358 MiB - 2º Boot sem PIM & Akonadi
    2018-02-17 - 355 MiB - PrtScn alterou: 357 MiB - ainda sem AutoLogin
    2018-02-17 - 348 MiB
    2018-02-21 - 342 MiB - PrtScn alterou: 343 MiB
    2018-02-23 - 351 MiB - PrtScn alterou: 352 MiB
    2018-03-03 - 365 MiB
    2018-03-13 - 365 MiB - PrtScn alterou: 367 MiB
    2018-03-19 - 365 MiB
    2018-03-28 - 356 MiB - PrtScn alterou: 357 MiB
    2018-04-01 - 371 MiB - PrtScn alterou: 372 MiB
    2018-04-21 - 351 MiB - após PrtScn: 399… 352 MiB

    Após a recuperação:

    2018-04-27 - 514 MiB - PrtScn alterou: 517 MiB
    2018-04-28 - 517 MiB
    2018-04-30 - 502 MiB - PrtScn alterou: 503 MiB
    2018-05-01 - 499 MiB - PrtScn alterou: 503 MiB
    2018-05-05 - 501 MiB - PrtScn alterou: 503… 528… 502 MiB
    2018-05-17 - 502 MiB - PrtScn alterou: 504 MiB

    Após remover Akonadi-server:

    2018-05-21 - 331 MiB - PrtScn alterou: 333 MiB… 358… 331 MiB
    2018-05-21 - 330 MiB - PrtScn alterou: 331 MIB… 356… 331 MiB
    2018-05-21 - 331 MiB - PrtScn alterou: 333 MiB… 356… 331 MiB
    2018-05-22 - 332 MiB - PrtScn alterou: 333 MiB
    2018-05-23 - 332 MiB - PrtScn alterou: 331 MiB
    2018-05-23 - 331 MiB
    2018-05-28 - 331 MiB - PrtScn-alterou: 336 MiB

    Obs.: Números observados cerca de 1 minuto após o carregamento do KDE, — quando o uso de Memória RAM se estabiliza.

    O primeiro número é a observação visual antes do PrtScn, — pois às vezes o gnome-screenshot interfere na Memória RAM antes da captura, e grava a imagem com um número alterado (exceto quando omitido, acima).

    Entre a captura e o final da gravação, o gnome-screenshot ainda costuma elevar mais um pouco esse número (cerca de +25 MiB), retornando ao patamar inicial após cerca de +25 segundos.

    Medição do uso de Memória RAM, — 1 minuto (↓) após o carregamento completo do KDE

    Os gráficos de uso de CPU são de 2 minutos (120 pixels), — e o final da passagem do pequeno pico inicial pelo centro (↓) assinala 1 minuto após as notificações de carregamento completo do KDE, conexão de Rede etc.

    Remoção do Akonadi


    Remoção “apenas” do Akonadi-server, — um modo de remoção parcial do PIM

    A primeira remoção do PIM, Baloo, Akonadi tinha sido feita logo na instalação do Devuan 2 Beta, em meados de Fevereiro, — e não causou nenhum desastre durante 2 meses.

    21 Mai. 2018 - Diante da possibilidade de novos desastres, agora foi removido “apenas” o próprio Akonadi-server, — com suas dependências automáticas, — o que evitou gastar tempo à procura de vários itens, e no teste das dependências de cada um:

    Efeitos da remoção “apenas” do Akonadi-server, — em comparação com a remoção de Fevereiro

    Commit Log for Mon May 21 08:06:07 2018

    Removed:

    accountwizard
    akonadi-server
    akregator
    kaddressbook
    kde-config-mailtransport
    kde-standard
    kdepim-addons
    kdepim-runtime
    kdepim-themeeditors
    kmail
    knotes
    korganizer
    libkf5akonadicalendar5
    libkf5akonadicontact5
    libkf5akonadicore-bin
    libkf5akonadimime5
    libkf5akonadisearch-bin
    libkf5akonadisearch-plugins
    libkf5alarmcalendar5
    libkf5calendarsupport5
    libkf5eventviews5
    libkf5gravatar5
    libkf5incidenceeditor-bin
    libkf5incidenceeditor5
    libkf5kaddressbookgrantlee5
    libkf5kdepimdbusinterfaces5
    libkf5ksieveui5
    libkf5libkdepim-plugins
    libkf5libkdepim5
    libkf5mailcommon-plugins
    libkf5mailcommon5
    libkf5mailimporter5
    libkf5mailtransport5
    libkf5messagecomposer5
    libkf5messagecore5
    libkf5messagelist5
    libkf5messageviewer5
    libkf5pimcommon-plugins
    libkf5pimcommon5
    libkf5templateparser5
    libkolab1
    task-kde-desktop

    A lista é apenas um pouco menor, — mas remover “só” 1 pacote deu muito menos trabalho.

    Agora, a lista dos “Auto-Removíveis” é de 240 pacotes, — inclusive todo LibreOffice, de novo.

    O caso do Debian testing


    Comparativo dos sistemas Linux instalados em 16 Mai. 2018

    Só para referência, vale lembrar que o Debian foi instalado “Jessie” e transformado, — do modo mais atabalhoado possível, — em “Testing” (não “Stretch”). No devido tempo começou a se apresentar como “Stretch”, e atualmente como “Buster / Sid”.

    No Debian testing, a remoção do PIM-Baloo-Akonadi foi tão completa quanto possível, — e nesses 20 meses, seu KDE evoluiu do KDE 5.8.0 até o KDE 5.12.5, — ao passo que o Devuan 2 Beta continua com o mesmo KDE 5.8.6 que tinha há 3 meses.

    Não se trata de comparar a enormidade de recursos, desenvolvedores, testadores, mailing-lists, foruns etc. do Debian com o esforço heroico realizado pela brava comunidade do Devuan, — portanto, a constatação de que o Debian (mesmo sob tortura de um mentecapto) segue firme e forte, deve ser tomada única e exclusivamente como referência para análise. — Nada além disso.

    Por outro lado, a recuperação (simples e fácil) do KDE Plasma foi uma demonstração cabal de solidez, consistência e capacidade de regeneração do Devuan 2 Beta, — mesmo cruelmente amputado e submetido às mais torpes torturas.

    Tanto no Debian quanto no Devuan, a montagem automática de partições adicionais dos HDDs se faz pelo arquivo /etc/fstab, — e apenas as do SSD externo pelo udisks2, — via System settings >> Removable devices.

    — … ≠ • ≠ … —

    Without-SystemD



    Debian's


    Postado por Mboaba às quinta-feira, maio 17, 2018 0 comentários
    Marcadores: , , , ,
    Assinar: Postagens (Atom)