 |
| Quadro comparativo dos sistemas Linux mantidos para aprendizado |
10 Jun. 2017 - A instalação do Arch Linux KDE, no último final-de-semana, teve o dom de lembrar os objetivos da brincadeira, — reduzir minha dependência de “decisões proprietárias”, — e representou um belo passo à frente.
Pela primeira vez, um sistema totalmente “comunitário” resolveu uma das tarefas mais renitentes, — navegar uma série de “Páginas” do Facebook (entre outras redes), 3 ou 4 vezes por dia, com direito a assistir os vídeos que interessarem, — sem que o velho hardware fique devagar-quase-travando.
27 Jun. 2017 - A alegria não chegou ao final do mês.
Para ficar “perfeito”, ainda falta conseguir rodar o Google Earth (sem placa aceleradora 3D) e rodar no Wine alguns velhos aplicativos, necessários ao aproveitamento do trabalho acumulado em 27 anos de arquivos digitais, — coisa que não era de se tentar logo na primeira semana. — Mas isso não é necessário todos os dias, e justifica carregar outro Linux, quando for o caso. Assim, foi possível trabalhar 7 dias seguidos, quase que apenas no Arch Linux KDE.
Experiências abortadas
 |
| Quadro comparativo dos sistemas Linux instalados até o início de Junho |
Os bons resultados com Arch Linux tornaram dispensável manter o Manjaro e o Antergos, neste momento. É dispersivo, tentar aprender (e lidar com) coisas demais. — Além disso, o Antergos e o Sabayon tinham parado de funcionar (ambos na noite de 28 Maio, quanta coincidềncia), exigindo tempo e atenção para descobrir as causas. — O Fedora andava meio estagnado, sem muito tempo para pesquisar e torná-lo mais “usável”. — Enfim, uma segunda experiência com Mageia (“instalação clássica”) apresentava poucas vantagens, que justificassem aquela duplicação paralela.
Essas 10 partições (raiz + home) foram formatadas, para eliminar até mesmo as configurações. — Ficam as Capturas de tela, fotos, anotações e alguns arquivos TXT, para exame caso haja motivo.
Restrições ao “modo root”
 |
| Atalhos para Krusader em modo root, dentro do próprio Krusader |
Não foi sonho, nem alucinação, — capturas de tela garantem que “Krusader - modo Superuser” (root mode) era um item normal no Menu do Kubuntu, do Debian testing, do KDE Neon e do Manjaro, pelo menos:
- 2016-12-24_11-28-12_Kubuntu_Menu-root-Krusader
- 2017-01-04_13-56-12_Manjaro_Krusader-root
- 2017-01-12_18-16-30_Neon_Krusader-root-mode
- 2017-02-07_19-16-01_Debian testing_Krusader-modo-root
Nos últimos meses, isso desapareceu do Menu do KDE Neon (talvez, ao ser reinstalado), — e do Manjaro (após alguma atualização).
 |
| Caminho existente no Linux Mint 18 KDE, desde Agosto 2016 |
No Linux Mint KDE, nunca vi “Krusader modo-root” no Menu, desde quando foi instalado, há cerca de 1 ano, — mas, dentro do Dolphin, pode-se clicar com o botão direito em uma pasta, e abri-la “como root”, — por enquanto:
- 2016-08-26_17-09-43_Mint_Dolphin-abrir-pasta-como-root
- 2016-12-21_12-04-45_Mint_Dolphin-abrir-boot-grub-como-Root
A rigor, não é uma diferença “entre distros”, mas entre as que se atualizam mais depressa, ou mais devagar. As mais “avançadas” recebem boas, — e más — novidades primeiro.
Há uma enxurrada de reclamações e pedidos de ajuda, — bem como 2 explicações principais: — (a) Seria uma “tutela” para evitar que novatos se machuquem, tipo um “cercadinho” para bebês; — ou (b) Foram bloqueados Kate e Dolphin por “kdesu”, como medida temporária, até que seja sanada uma brecha de segurança (previsão: final de 2017).
A explicação (a) causa revolta de uns, em nome da liberdade, — e defesa de outros, em nome de se fazer tudo por comandos, — mas parece ser lenda urbana ou, no mínimo, uma deformação da informação correta. Desde Fev. 2017, uma linha de código diz ao Kate e ao Dolphin que abortem, quando chamados por “kdesu”.
+#ifndef Q_OS_WIN
+ // Check whether we are running as root
+ if (getuid() == 0) {
+ std::cout << "Executing Dolphin as root is not possible." << std::endl;
+ return EXIT_FAILURE;
+ }
+#endif
Um teste com “kdesu”, — feito apenas no Arch Linux, — mostra que não carrega Dolphin, Kate, KWrite. O único que abre é o Krusader.
- E no entanto, o KDE Neon retirou “Krusader - Superuser” de seu Menu. — Mas há várias outras coisas estranhas acontecendo no KDE Neon, — inclusive, um crash renitente do Konqueror, todas as vezes que é aberto. Pode ser só comigo.
Por enquanto, isso deixou de ser problema grave, enquanto se possa chamar “kdesu krusader”, — ou abri-lo como Usuário, e dentro dele ir ao menu “Ferramentas → Krusader em modo root”. — Isso é mais demorado, além de deixar 2 Krusader abertos, mas no curto prazo é uma alternativa. Para encurtar caminho, também se pode criar esse atalho na Barra de ferramentas.
Painel lateral do Konqueror
Ultimamente, também começou a desaparecer o painel lateral (F9) do Konqueror, — que existia no Kubuntu, no Mint, no Debian e no KDE Neon.
No KDE Neon, o desaparecimento foi notado após a atualização de 19 Dez. 2016, — que removeu “dolphin4”, entre outras coisas.
Depois, todos aqueles pacotes foram reinstalados. — Não houve conflito, — mas tampouco trouxe de volta o painel lateral.
No Mageia, Manjaro, Antergos, Sabayon, — e agora, no Arch, — o Konqueror já veio sem painel lateral (F9).
Atalhos no Gwenview
Após uma atualização massiva de KDE-apps (17.04.2-1) no Arch Linux, em 8 Junho, o atalho personalizado “Esc” deixou de funcionar, para sair do Gwenview. O atalho continua aplicado, — foi reaplicado etc., — mas não funciona mais.
Dois dias depois, uma atualização massiva de KDE-apps (17.04.1 para 17.04.2) produziu o mesmo problema no KDE Neon.
Índice
- 10 Jun. 2017
- Experiências abortadas
- Restrições ao “modo root”
- Painel lateral do Konqueror
- Atalhos no Gwenview
- 14 Mai. 2017
- Linux Mint
- Manjaro
- Mageia 6 sta2
- Grub, grubs
- Por causa de umas questões paralelas
- Março ~ Maio 2017
- 13 Mar. 2017
- 24 Fev. 2017
- “Derivados” do Debian
- Sistemas e tarefas
- Escolha dos “não-debian”
- Agosto 2016 ~ Fevereiro 2017
- Posfácio
- Não-debians [Menu]
14 Mai. 2017
 |
| Quadro comparativo dos sistemas Linux instalados, no final da tarde de 14 Mai. 2017 |
Trabalhando dias seguidos no Linux Mint 18 KDE, um aviso na noite de 13 Mai. 2017 apresentou um festival de pacotes para atualizar, — 106, além de 11 novos, — e o resultado foi a passagem do KDE Plasma 5.8.5 para 5.8.6, e do KDE Frameworks 5.28 para 5.33.
Nada de tão espetacular, se você já tinha outros sistemas com essas (e até outras) versões mais “novas”, — ótimo antídoto contra ansiedade por novidades. — Você vê que novidades não são o prêmio-grande da loteria, o mundo continua girando, e versões “antigas” atendem muito bem suas necessidades.
Você mata a curiosidade, — e ainda aprende alguma coisa sobre outras distribuições Linux, — sem botar em risco sua “trabalhabilidade”.
Nesta semana, — pois não houve verificação diária, — Fedora, Manjaro e Sabayon também passaram do KDE Plasma 5.9.4 para 5.9.5.
Como o acompanhamento se tornou trabalhoso, deixam de ser registradas “correções” de Kernel, para simplificar.
Linux Mint
 |
| Atualizador “mintUpdate”, com a seleção mais adequada à integridade do Linux Mint |
Após alguns transtornos na migração do Linux Mint 18 para 18.1, — que evidenciaram o quanto ele é fundamental para meu trabalho, — acabei reinstalando o Linux Mint 18 KDE e, desde então, o Synaptic foi abandonado, em favor do mintUpdate, que oferece a seleção mais adequada à manutenção da integridade do sistema, nas atualizações do dia-a-dia.
Não que o Synaptic pareça ter “culpa” por aqueles transtornos, — o upgrade foi feito pelo mintUpdate, — mas gato escaldado evita água fria.
 |
| Há tempos o Synaptic oferece 35 atualizações, que até hoje o mintUpdate não recomendou |
O Synaptic continua em uso para instalação de novos pacotes (por ser mais prático), — e também para copiar e documentar o Histórico das atualizações feitas pelo mintUpdate, — porém há tempos ele oferece 35 atualizações que, até hoje, o mintUpdate não parece recomendar. Melhor deixar quieto, a menos que estude muito tudo aquilo.
Portanto, sigo ignorando essas 35 atualizações indicadas pelo Synaptic, — e o Linux Mint 18 KDE (reinstalado) segue funcional. — Um dia, isso terá de ser enfrentado (ou nunca), mas no momento não há motivo para caçar trabalho; muito menos, pressa em caçar confusão.
Manjaro
 |
| Removendo pacote com dependências problemáticas, que obstruía atualizações do Manjaro |
Mais uma vez, o Manjaro consolidou a sensação de generosidade em problemas, — bem como em localização rápida de soluções, — gerando um aprendizado agradável.
Ao ser carregado, já trata de procurar atualizações, automaticamente, — é fácil perceber que isso está ocorrendo, e basta aguardar 1 ou 2 minutos. — Logo apresentou um festival de 380 pacotes.
Nas primeiras tentativas, usando a opção de deflagrar o processo a partir da notificação no Painel, não havia resposta.
Apenas abrindo o Octopi e mandando instalar as 380 atualizações pela barra inferior de sua janela, resultava em um diálogo, informando erro e perguntando se “deseja executar essa transação em um Terminal”.
Tentando pelo Terminal, informava não ser possível satisfazer às dependências de 1 pacote.
A busca pela expressão, — “Manjaro, falha ao preparar a transação (não foi possível satisfazer as dependências)”, — localizou ocorrências absolutamente iguais, em vários fóruns, logo no topo dos resultados, — e as respostas sugerem que isso costuma ser causado por desatualização do repositório tentado.
Encontram-se sugestões de editar o “/etc/pacman.d/mirrorlist”, — caso o primeiro repositório esteja com status “desatualizado”, — movendo outro repositório para o topo da lista.
Até pensei em tentar, mas (felizmente!) não encontrei modo de editar o arquivo com Kate ou KWrite, usando “sudo”, nem “su”, — e tampouco encontrei Dolphin / Krusader “as root” no Menu.
Faltava um desses 3 gerenciadores de arquivos, — e tentei instalar, na expectativa de que automaticamente gerasse uma entrada de “as root” em Menu → Sistema (já vi isso acontecer, em algumas distros), — mas o Octopi se declarou em greve, até que o problema fosse resolvido.
De qualquer modo, editar o arquivo de configuração dos Repositórios não seria um bom caminho, e analisando as imagens, acabou ficando claro que o australiano “manjaro.uberglobalmirror”, — que estava no topo do arquivo “/etc/pacman.d/mirrorlist”, — constava como “atualizado”, no Manjaro repository - Status of mirrors.
Portanto, substituí-lo por outro qualquer, escolhido “no olho”, não ia resolver nada, — e como existem dezenas de espelhos para escolher, o usuário que tente esse caminho arrisca perder horas e horas, copiando e colando, um após outro, até ficar maluco, — ou cometer algum erro, e piorar mais ainda a situação.
Felizmente, numa das 3 postagens sobre o Manjaro aqui no Byteria, estava registrado o caminho correto para “editar” o arquivo “/etc/pacman.d/mirrorlist”. — Trata-se de verificar o status de todos os repositórios, em busca dos mais rápidos no momento, com exclusão dos desatualizados:
sudo pacman-mirrors -g
Isso não resolveu o problema, — mas eliminou uma hipótese, poupando carradas de tentativas inúteis num caminho errado.
Por via das dúvidas, foi limpado o cache, — também não resolveu, mas tampouco podia fazer mal. — No mínimo, evita a ocupação crescente da partição de sistema com 1,2 GiB de pacotes baixados e já instalados.
A próxima sugestão tentada, — remover o pacote encrencado, — foi a que resolveu o problema.
Por algum motivo, — erro de digitação?, — o comando não deu resultado:
pacman -R gstreamer0.10-good-plugins
Foi tentado, então, removê-lo pelo próprio Octopi, — que gentilmente interrompeu sua greve e fez este imenso favor.
Depois disso, o Octopi consentiu em fazer a atualização, — não de 180 pacotes, mas de 187, — e todos foram felizes para sempre.
Ou, nem tanto, — havia outras 12 ou 13 atualizações do AUR, que nunca entendi como mandar instalar. — Com a remoção desse pacote + 1 dependência, caíram para 10 ou 11 atualizações.
Tentá-las, parece equivalente a tentar a perdição, — pisca um aviso em vermelho, de “Pacote sem suporte - Potencialmente perigoso!”, — e por enquanto, a opção é digitar “A” para abortar a operação. Pelo menos, até fazer alguma ideia do quê se trata, para quê serve etc.
Ainda que um “aprendizado” miúdo como esse não pareça levar a grandes coisas, é um modo tranquilo, — sem tomar tempo, — de aplainar um bicho-papão do imaginário sobre pacotes Arch etc.
Quando o causo começou a tomar tempo demais, — das 22:10 às 22: 50, — foi deixado de lado, até concluir as atualizações dos demais sistemas. Não sendo indispensável ao trabalho, o Manjaro poderia esperar essa atualização, se necessário, até outro final-de-semana. Bastava um asterisco no Quadro comparativo, e uma anotação no caderno, com a faixa horária das Capturas de tela, — de “2017-05-13_22-10-04_Ma.jpg” até “2017-05-13_22-49-57_Ma.jpg”.
Terminado o giro pelos outros 10 Linux, o problema voltou a ser examinado, e acabou resolvido, — de “2017-05-14_00-05-50_Ma.jpg” até “2017-05-14_00-44-11_Ma.jpg”.
Em algum momento, — antes? agora?, — voltou a funcionar a opção do Octopi de “executar em um Terminal”, que andava fora de combate, havia várias semanas.
Mageia 6 sta2
 |
| Primeira fase de uma atualização em 2 etapas, no Mageia |
Mageia apresentou, de início, apenas 1 atualização, — urpmi, — e imaginei que, a partir dele, talvez decorressem outras atualizações. — Mera suposição de leigo, em vista de 2 ou 3 casos semelhantes.
E, de fato, tão logo concluiu essa primeira etapa, foram propostos outros 76 pacotes para atualização, — porém isso não levou a qualquer alteração perceptível do sistema, em relação ao status do dia 8.
Só no dia seguinte (14), houve uma atualização “normal”, — em “etapa única”, com 22 pacotes sugeridos, inclusive Kernel.
Também no dia seguinte (14), o Resumo semanal do Mageia Blog chamou atenção para as menções de “RC” e “pronto”, nas listas de discussão, indicando que o lançamento do Mageia 6 está próximo.
Grub, grubs
 |
| Correção manual do Grub do openSUSE, com Kwrite |
Aproveitando o embalo do Sábado à noite, foi conectada a unidade SSD, carregados os outros 10 sistemas Linux, e atualizados, um após outro, até cerca de 0:48 do Domingo. — Em seguida, foi atualizado o Grub (controlado pelo openSUSE), para detectar um ou outro Kernel novo e gerar o novo Menu de inicialização.
O comando é utilizado “por extenso”, — não vem de fábrica nenhum script tipo “update-grub”:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Usar o Grub do openSUSE, — chamado a partir da trilha inicial (trilha MBR) do sdc, — é uma necessidade, enquanto não entender por que só o openSUSE consegue gerar uma entrada de Menu de inicialização capaz de carregá-lo.
Ou, até aprender como corrigir o Grub gerado pelos demais Linux, para que consiga carregar o openSUSE.
Até o momento, o Grub gerado pelo openSUSE exige 2 correções manuais, para conseguir carregar o Manjaro, e o KDE Neon reinstalado.
No caso do Manjaro, o Grub gerado pelo openSUSE precisa da seguinte correção manual, — desde sempre:
Nas linhas onde aparece:
ucode.img
Substituição nas entradas com o Kernel atual:
ucode.img /boot/initramfs-4.9-x86_64.img
Ou, nas entradas com o Kernel anterior:
ucode.img /boot/initramfs-4.4-x86_64.img
No caso do KDE Neon User Edition, — instalado em 31 Mai. 2016, — o Grub gerado pelo openSUSE costumava funcionar perfeitamente, até o dia em que aquela instalação foi deletada por distração, há algumas semanas. Foi necessário, então, reinstalar o KDE Neon.
Porém, as atuais imagens ISO do KDE Neon parecem não se entender direito com meu computador, — embora ele não inclua nenhum hardware lançado há menos de 3 ou 4 anos, — e não consegui encontrar nenhuma ISO mais antiga para baixar (sim, tinha usado Pendrive; não gravei DVD, nem guardei a ISO antiga em HDD).
Por conta disso, agora o Grub gerado pelo openSUSE precisa ser manualmente corrigido, para carregar o KDE Neon.
Todas as ocorrências de:
root=UUID=XXXXXXX ro quiet splash $vt_handoff
Precisam ser globalmente substituídas por:
root=UUID=XXXXXXX ro nomodeset $vt_handoff
Obs.: - Inicialmente, a substituição era outra, — também funcionava (acho), — mas experimentei a opção acima, por algum motivo, e não me preocupei mais com isso:
root=UUID=XXXXXXX ro quiet splash nomodeset
A inclusão do UUID na substituição global evita afetar as entradas de outras distribuições Linux, que também incluem “ro quiet splash $vt_handoff”.
Tudo isso é mais fácil e rápido de fazer, do que de explicar, — mas não deixa de ser chato. — Um motivo a mais, para percorrer o circuito de atualização dos 11 Linux apenas 1 vez por semana, se tanto. Mais por curiosidade, do que por necessidade, — apenas 2 ou 3 são usados no dia-a-dia.
Pela manhã foram carregados os 11 sistemas, um após outro, — para documentar pelo KInfocenter as novas versões do Plasma, Frameworks, Qt e Kernel, — sem verificar o Quadro das “funcionalidades”.
Portanto, o Quadro comparativo é apenas aproximado, — não há como capturar 11 “realidades”, uma após outra, sem que alguma delas se altere durante o processo. — Tente levar 11 crianças ao Zoo.
Por causa de umas questões paralelas
Cabe deixar claro que não sou expert em coisa alguma, no Linux, — mero usuário, hesitante até em pretender ser “médio” fora do Kubuntu / Linux Mint / KDE Neon, — e, de fato, após 10 anos batendo cabeça, é só em 2 desses 3 que consigo fazer todo o trabalho.
É comum passar dias, semanas, sem precisar do CorelDraw, Dreamweaver ou MS Word, — para reutilizar trabalho acumulado na forma de arquivos digitais desde 1990, — mas, pela Lei de Murphy, é quando você está impossibilitado que a necessidade aparece.
Portanto, não vamos louvar demais o KDE Neon, — ficam Kubuntu LTS e Linux Mint 18 KDE.
No entanto, já instalei e usei o GoogleEarth no KDE Neon por quase 1 ano, antes de detonar o sistema (por simples distração), e nada sugere que não consiga reinstalar esse recurso, — principal substituto do AutoCAD, que em anos recente vinha sendo usado apenas para gerar mapas. — A falta de urgência em fazer isso mostra o quão tranquilizante é ter mais de 2 sistemas em paralelo (dualboot).
Bastou um upgrade (18 → 18.1) para deixar o Linux Mint com a língua de fora, durante alguns meses.
E bastou uma distração, para deletar um KDE Neon que, durante quase 1 ano, se mostrou estável e produtivo, — coisa que 3 imagens ISO e 2 reinstalações ainda não lograram alcançar outra vez.
Portanto, 1 sistema 100% funcional é pouco, 2 é bom, 3 já começa a dar trabalho, — mas, pela Lei de Murphy, quem tem 2 tem 1, quem tem 1 pode ficar sem nenhum. — Vale a pena ter 3, e não custa nada experimentar 5 ou 11, em busca de novas alternativas. De preferência, bem diferentes entre si, e todas afastadas das atuais.
Notar que todos os atuais “2 ou 3” dependem, direta ou indiretamente, da previsibilidade do tio Mark Shuttleworth, — vale dizer, não dá para repousar em serviço, — em especial, se você é apenas um “usuário médio”, e ainda por cima, sem capital para contratar assessoria urgente, de uma hora para outra. Sem aviso prévio.
Muito mais frequente, é ter de acessar o Facebook no Chromium, — não que o Firefox seja “pior” ou “melhor”; apenas, preciso manter os Bookmarks sincronizados e disponíveis nos vários sistemas, sem complicações de exportar / importar entre 2 browsers diferentes (sim, faço isso, às vezes).
Nesse aspecto, parece promissor que o Mageia e o openSUSE se mostrem capazes de enfrentar o recurso “Páginas” do Facebook (não me refiro ao Feed, Grupos ou Perfis), sem sucumbir à lentidão ou congelamento, — mas desanimador que isso venha associado à incapacidade de assistir vídeos. — Não é tão indispensável assistir vídeos, mas convenhamos que viver na precariedade não é o sonho de consumo de ninguém.
É curioso que o Debian (testing ou Jessie, tanto faz), o Manjaro e o Zesty Zapus se comportem de modo diametralmente oposto, — neles consigo assistir vídeos (inclusive no Feed, Grupos e Perfis do Facebook), mas sucumbem diante da sobrecarga representada pela simples navegação em “Páginas” do Facebook (mesmo sem tentar ver qualquer vídeo). — Isso talvez tenha fácil explicação, mas procurá-la não é tão urgente, enquanto puder dispor de 2 sistemas 100% funcionais, e um terceiro habilitado para 90% dos usos necessários.
Enfim, vale notar que inúmeras outras tarefas de uso diário, — Xsane, OCRFeeder / gImageReader, Gimp, Okular, Kamera, Kate / KWrite, LibreOffice, Chromium (para tudo mais), WhatsChrome, K3b, ScreenRuler / KRuler, pyRenamer / KRename, conversão PNG → JPEG, Dolphin / Krusader / Konqueror, busca avançada etc., — funcionam 100% bem, em todos os 11 sistemas instalados até agora, de modo que ao carregar o Antergos ou o Sabayon (os mais recentes e menos familiarizados) não é necessário sair correndo. Apenas, (ainda) são incômodos para trabalhar por longos períodos.
Março ~ Maio 2017
 |
| Quadro comparativo dos sistemas Linux instalados, em 8 Mai. 2017 |
xx
 |
| Quadro comparativo dos sistemas Linux instalados, em 25 Abr. 2017 |
xxx
 |
| Quadro comparativo dos sistemas Linux instalados, em 17 Abr. 2017 |
xxx
 |
| Quadro comparativo dos sistemas Linux instalados, em 31 Mar. 2017 |
xxx
13 Mar. 2017
 |
| Quadro comparativo dos sistemas Linux instalados, no final da tarde de 13 Mar. 2017 |
Com a instalação do Antergos e do Sabayon, carregar e atualizar, sucessivamente, os 11 sistemas deixou de ser tarefa para 40 ou 50 minutos.
No dia 13 Mar. 2017, por exemplo, alguns fatores contribuíram para que essa tarefa se prolongasse por mais de 4 horas, — das 13:50 até cerca das 18:00.
Ao final de tão longo período, é muito possível que o primeiro sistema a ser atualizado já tivesse novas atualizações disponíveis.
O Antergos só foi atualizado às 16:45, — o que pode ter contribuído para ser o único a apresentar Frameworks 5.32 nesse dia.
Após 20:10, voltei a carregar o KDE Neon, para concluir outras tarefas, e não apresentou novidades. — Mas no dia seguinte, logo cedo, acusou 167 pacotes atualizáveis, e também avançou para Frameworks 5.32.
Naturalmente, não dá para repetir a brincadeira todos os dias, — senão, é o feijão quem vai ficar desatualizado.
24 Fev. 2017
 |
| Quadro comparativo dos sistemas Linux instalados, com algumas diferenças de funcionalidade |
Com a instalação do Manjaro, openSUSE, Fedora e Mageia, — estranhos ao universo Debian / Ubuntu, já familiar, — acabou-se a moleza.
Ainda há espaços (no SSD externo) para instalar mais 3 sistemas, — e foram feitos preparativos para
 |
| Mageia 5, — instalação ainda não relatada |
Os relatos da instalação e configuração do Manjaro e do openSUSE estão bastante incompletos, — qualquer avanço exige tempo para organizar centenas de prints, anotações, além de bastante leitura e aprendizado, para ser útil, — enquanto o do Fedora ainda se resume a 3 ou 4 tópicos isolados, e o do Mageia (
Além disso, as rotinas adotadas para usar, atualizar e registrar regularmente a experiência com os vários sistemas, agora consomem tempo excessivo, — sem falar no “processamento” posterior das observações, para consolidar o conhecimento adquirido.
“Derivados” do Debian
Enquanto isso, os “derivados” do Debian acumulam algumas questões a serem resolvidas.
Desde 5 Fev. 2017, o desenvolvimento do Debian 9 Stretch foi “congelado”, a caminho de se tornar o novo Debian “stable”, daqui a algumas semanas. No entanto, a atual instalação foi orientada para repositórios “testing”, — não “Stretch”, — na expectativa de que continue a evoluir. Mas o que significa isso, na prática, é o que cabe agora observar, para aprender. E cedo ou tarde, algumas opções terão de ser feitas. Ficar no “stable” ou seguir em frente? Talvez já tenha avançado demais, e a essa altura voltar a “stable” implique em algum downgrade. Qual a vantagem disso?
O KDE Neon User Edition, — instalado quase que no nascedouro, quando nada era claro para um leigo, — lançou sua versão LTS, em 9 Dez. 2016, fixado no KDE 5.8. Talvez coubesse uma escolha, naquele dia, — entre ficar no LTS, ou seguir em frente, — mas, agora, a instalação já está no KDE 5.9.2. Seria necessário reinstalar, pois não parece fácil fazer o downgrade (se é que é possível). No entanto, para todos os efeitos práticos, o KDE “rolling-release” tem se mostrado sólido o bastante, para liquidar qualquer “medo de mudanças”. De fato, até hoje se mantém muito mais “produtivo” do que o Zesty Zapus, por exemplo. Nenhum motivo real para reinstalar / retroceder à versão LTS.
O Kubuntu 17.04 Zesty Zapus, — instalado lá no início de seu desenvolvimento, — já lançou versões Alpha 1 e 2 (Janeiro), e Beta 1 (Fevereiro). E agora? Manter e aproveitar a onda de debates nos fóruns, ou pular para o início do 17.10? A ideia inicial era acompanhar a evolução do Kubuntu, para não topar despreparado eventuais surpresas do futuro 18.04 LTS. No entanto, o mais lógico talvez seja eliminá-lo, — e usar seu espaço para o
Por fim, o Linux Mint, — único em que consigo realizar todas as tarefas necessárias (além do Kubuntu), — sofreu sequelas no upgrade do 18 “Sarah” para 18.1 “Serena”. Continua fazendo tudo, porém com uso excessivo de CPU (e algum aquecimento). É preciso descobrir a causa e a solução ou, em último caso, reinstalar. Mas reinstalar, com ou sem formatação da partição-raiz? O problema poderia estar em alguma configuração na “/home”, e qualquer reinstalação seria perda de tempo? Formatar a “/home”, e perder vários anos de configurações acumuladas? Reinstalar versão 18 “Sarah” ou 18.1 “Serena”? Nessa hora, até o Linux Mint 17.3 KDE, — testado de passagem, em sessão Live USB, — faz um aceno saudosista, só para complicar as ideias.
- 28 Jan. 2017 - Upgrade, — e início do problema.
- 1º Mar. 2017 - Foi reinstalado o Linux Mint 18.1 “Serena” KDE, — sem formatar a partição-raiz, — e o problema continuou.
- 8 Mar. 2017 - O problema pareceu se resolver sozinho, após uma atualização “com erro” (vai entender), — pero, no mucho! — Alguma sequela ainda se manifestava.
- 29 Abr. 2017 - Reinstalado Linux Mint 18 “Sarah” KDE, — com formatação da partição-raiz (não da /home). — Algum problema continuou, mas acabou cedendo perante algumas manipulações. Às vezes, algum problema ainda reaparece, mas não tem atrapalhado.
O Knoppix é um caso a parte, — curiosidade que vem desde os tempos do Kurumin, e que até meados de 2016 nunca tinha conseguido carregar. — Não é uma “distro”, no sentido comum da palavra. Não se destina a ser “instalado”, muito menos receber atualizações. É concebido para rodar como “Live CD / DVD”, ou “Live USB”, — e neste caso, a “instalação” no Pendrive permite configurar um arquivo ou partição de “persistência”, para não perder arquivos e configurações, de uma sessão para outra. — Uma vez compreendido isso (“na pele”), tornou-se minha ferramenta preferida para manutenção, particionamentos etc. (embora também tenha alguns Live CDs do GParted Live, Boot Repair Disk, Memtest86).
Sistemas e tarefas
 |
| Sistemas instalados em paralelo, desde 2007 |
A escolha desses sistemas vem do histórico pessoal, — começando pelo Kurumin, em fins de 2007, e Kubuntu a partir de 2009, — assim como as tarefas exigidas (tabuladas só as que apresentam alguma dificuldade em um ou outro sistema).
O “paralelismo”, — sistemas lado-a-lado (dual-boot / multi-boot), ao invés de máquinas virtuais, — também vem do histórico pessoal, pois no início era relativamente frequente “escangalhar” um sistema, por falta de conhecimentos. Ter um “estepe” era prudente, em casos de emergência.
Esse espaço reservado para um “segundo Linux” foi aproveitado para experimentar alternativas, — em especial, Debian (quase sempre KDE) e Linux Mint (Xfce, Cinnamon), — embora também tenha experimentado Ubuntu, Xubuntu, Big Linux e outros, que não duraram nem deixaram lembrança. [Obs.: o quadro acima foi simplificado. Na verdade, chegou a haver 3 sistemas instalados lado-a-lado, no início de 2009].
Por falta de conhecimentos e consequente dificuldade com as “diferenças”, só houve comparação mais sistemática a partir de 2015, quando no “segundo” espaço foi instalado o mesmo Kubuntu “principal”, — com a diferença de um ser 32bit, e o outro 64bit, — o que permitiu configurá-lo “exatamente igual”, até o último detalhe. Pela primeira vez, as configurações deixaram de ser um tanto vagas, coisas feitas 1 vez a cada 2 anos e logo esquecidas (apesar das anotações dispersas no “caderno de informática”), para se tornarem alguma coisa efetivamente “mapeada”.
Depois disso, foi possível sistematizar também as diferenças entre o Kubuntu 14.04 e o Linux Mint Cinnamon 17.3, na primeira metade de 2016, — e abandonar definitivamente qualquer veleidade de usar outro ambiente, que não KDE.
A adoção do KDE também vem do histórico pessoal, — certa preferência, desde a década de 1990, por abundância de Memória RAM, que torna o computador mais “duradouro”, sem o custo de uma CPU de última geração e/ou upgrades frequentes. — O atual foi montado com 4 GB RAM, já vai para 8 anos (2009), e até hoje é mais do que satisfatório. Nenhum problema com KDE, nem qualquer necessidade de usar ambientes mais “leves”.
É possível que, se continuasse acompanhando a evolução do Windows, esta máquina já estivesse pondo a língua de fora, — e o uso exclusivo de Linux esteja prolongando seu valor de uso, — mas realmente não posso afirmar.
Em todo caso, fica evidente meu total desconhecimento de qualquer sistema que não fosse “derivado” do Debian, até o final de 2016.
Escolha dos “não-debian”
 |
| Sistemas Linux escolhidos entre os mais procurados no Distrowatch |
A ideia era selecionar sistemas de diferentes “troncos principais”, — mesmo que “derivados”, — para experimentar estruturas, o mais diferentes possível, umas das outras. O importante é que fossem razoavelmente afeitos ao usuário “comum”, — e de preferência, com bom número de usuários.
Mas logo ficou claro que esse conceito de “tronco” não faz muito sentido, — a menos que se estude o assunto com profundidade, abrangência, detalhamento e “tecnicalidade”, — coisas que fogem ao propósito de uma simples “aproximação inicial”, para começar a “ver como é”.
Slackware (30º no Distrowatch) pareceu pouco propício à brincadeira, — e nenhum “derivado” se mostrou atraente, — por isso ficou para o futuro.
OpenSUSE (5º) faz parte de outro “tronco”, — apesar de certa relação, muito longínqua, com Slackware, lá nas origens de seu ancestral SuSE, há uns 20 anos.
Red Hat (47º) acabou “representado” em excesso, — pelo Fedora (8º) e pelo Mageia (17º). — Talvez substitua um (ou ambos). Sem maiores conhecimentos, uma possibilidade parece ser o CentOS (11º). Ou, o próximo Mageia 6.
 |
| Antergos instalado. Não enfrenta bem o recurso “Páginas” do Facebook |
Arch Linux (12º) pareceu pouco afeito a um usuário “comum”, — Manjaro (4º) foi a escolha para começar. — Outra possibilidade é o Antergos (10º), cujo Live DVD infelizmente não carregou na primeira tentativa.
- 3 Mar. 2017 - Live DVD Antergos carregou normalmente na 2ª e na 3ª vez, — com algumas diferenças, como se não apenas o Wallpaper fosse randômico. — A instalação de pacotes oferece “excesso de opções” (AUR), e foi adiada após as primeiras experiências, até aprender quais opções (dos mesmos pacotes) são mais recomendáveis.
- 3 Jun. 2017 - Afinal, acabou sendo tão fácil instalar o Arch Linux, — por meio de 2 instaladores “gráficos”, — que fiz isso 2 vezes em 1 semana. E se mostrou tão bom, que o Manjaro e o Antergos puderam ser eliminados, para não complicar, no momento.
 |
| Sabayon instalado. Vem com Google Chrome (horrível). Não consegue enfrentar “Páginas” do Facebook |
Gentoo (44º) também não pareceu muito adequado, por enquanto. — Talvez, o Sabayon (55º).
- 4 Mar. 2017 - Instalado o Sabayon.
- 6 Jun. 2017 - Eliminado o Sabayon.
Para lá das fronteiras do BSD, até o momento, o TrueOS (29º) parece o mais razoável para uma primeira aproximação.
Para quem não entende nada de nada, isso tudo já parece programa suficiente para mais 1 ano.
Muita coisa, entre os primeiros 50 colocados no Distrowatch, — lembrando que é um ranking de visitas, mero “interesse em saber mais”, — ainda não foi examinada, ou foi olhada apenas por alto.
Zorin e Deepin foram descartados por serem “derivados” do Debian e/ou do Ubuntu.
Elementary OS e Solus Budgie chegaram a ser testados em sessões Live CD / DVD, — em parte, para conhecer seus ambientes, — e descartados, por falta de interesse pessoal fora do KDE.
Agosto 2016 ~ Fevereiro 2017
 |
| Quadro comparativo dos sistemas Linux instalados, em 6 Fev. 2017 |
Registros sobreviventes dos primeiros Quadros comparativos, desde Agosto 2016.
 |
| Quadro comparativo dos sistemas Linux instalados, em 26 Jan. 2017 |
xx
 |
| Quadro comparativo dos sistemas Linux instalados, em 6 Jan. 2017 |
xx
 |
| Quadro comparativo dos sistemas Linux instalados, em 21 Dez. 2016 |
xx
 |
| Quadro comparativo dos sistemas Linux instalados, em 26 Ago. 2016 |
Posfácio
Esta postagem foi publicada em 27 Fev. 2017, com as informações do penúltimo “capítulo”, — e desde então foram acrescentadas atualizações, — bem como um resumo dos poucos registros anteriores (faltou preservar sucessivas versões da planilha).
Esses registros servem, principalmente, para:
- Não esquecer o que já foi “descoberto”, — já ocorreu, 2 ou 3 vezes, de procurar solução para um problema, e o Google indicar uma página daqui mesmo, que nem lembrava mais;
- Servir de “índice” para facilitar a busca de anotações no “Caderno de informática” (sim, ele continua muito útil), — bem como, localizar Capturas de tela (daí, os dias e horas).
Índice
- 10 Jun. 2017
- Experiências abortadas
- Restrições ao “modo root”
- Painel lateral do Konqueror
- Atalhos no Gwenview
- 14 Mai. 2017
- Linux Mint
- Manjaro
- Mageia 6 sta2
- Grub, grubs
- Por causa de umas questões paralelas
- Março ~ Maio 2017
- 13 Mar. 2017
- 24 Fev. 2017
- “Derivados” do Debian
- Sistemas e tarefas
- Escolha dos “não-debian”
- Agosto 2016 ~ Fevereiro 2017
- Posfácio
- Não-debians [Menu]
— … ≠ • ≠ … —
Não-debians
- Mageia 6 - Kernel 4.14
- PCLinuxOS - instalação direta (sem sessão Live)
- PCLinuxOS - instalação e configuração
- Rosa Desktop Fresh R10 - live DVD, instalação e configuração
- openSUSE Tumbleweed - instalação e configuração
- Slackware Plasma 5 KDE - instalação e configuração
- Slackware - instalação e aprendizado (interrompido)
- openSUSE - removendo Snapper, PIM, Baloo e Akonadi
- Escolhendo Grub entre vários Linux
- Escolhendo (e aprendendo) Linux conforme as necessidades
- Arch Linux KDE - Instalação e configuração
- Mageia 6 sta2 - Instalação e configuração
- Montagem de partições no Antergos e no Manjaro
- Transição do Manjaro (rolling-release) para 17.0
- Sabayon 16.11 KDE - Instalação e configuração
- Fedora 25 KDE - Instalação e configuração
- Consertando o Manjaro após erro em atualização
- openSUSE Leap 42.2 - Instalação e configuração
- Instalação do Manjaro KDE 16.10.3 stable
- Mageia 5 KDE Live USB
- Fedora 24 alpha KDE em sessão Live USB
