quinta-feira, 6 de abril de 2017

Unity e dependência de “decisões proprietárias”

Ciclos de interesse pelo Knoppix, Kurumin, Ubuntu e Linux Mint, até o final de 2016

Usuário renitente do KDE, desde os primeiros passos no Linux, — à época do digno encerramento do Kurumin, — o anúncio oficial de que a Canonical vai abortar seu investimento no Unity8 parece não me fazer mossa.

Mas é um alerta para intensificar as experiências fora do universo “Ubuntu & derivados”.

Fugir da dependência de “decisões proprietárias” é uma das lições mais permanentes que a evolução da informática tem oferecido, reiteradas vezes, — empresas fecham, descontinuam projetos, ou os vendem (livram-se deles), ou são vendidas, e ótimos sistemas e aplicativos são desfigurados ou descontinuados.

Na memória estritamente pessoal, — cada um tem a sua, — poderia elencar a extinção do DR-DOS (Digital Research), do Ventura Publisher (Xerox), dificuldades à migração DOS / Windows de bons aplicativos antigos (como o dBase, entre outros). Nem precisaria citar a guerra desproporcional contra o Netscape (uma entre inúmeras). No mundo empresarial, nem sempre “vence o melhor”. Sói vencer o mais rapaz.

Felizmente, cedo aprendi a fazer mais do que meros backups em “formato proprietário”, — fazer backups em DIF (Data Interchange Format), por exemplo, de preferência em ASCII. — Hoje diria .CSV, plain-text, UTF8, Unicode. Nem foram ideias “minhas”; no máximo, bebi em boas fontes, antes que fosse tarde. Em grande parte, têm sido as tendências da comunidade de código-aberto, desde então.

Mas, nem sempre. Talvez publicações “em papel” estejam fadadas a desaparecer, — na cabeça dos “desenvolvedores”, quem sabe. — A depender do formato “.sla” do Scribus, por força permanecerão “desaparecidas” do meu trabalho. Por que, com mil cabritos, investiria na produção de arquivos “opacos”? É trabalhar para acumular algo que… nunca me pertencerá.

Os efeitos dessa “dependência”, portanto, vão muito além da mera “submissão financeira”, — taxas de servidão anual (até por “migração” forçada, sem que você precise de “nova versão”), — na medida em que afetem seu “estoque” de trabalho acumulado em arquivos digitais sob “formato proprietário”, bem como seu “estoque” de capacitações (aprendizado, treinamento).

Se, para uma empresa de grande porte, uma súbita “decisão proprietária” (externa a ela) já pode significar custos consideráveis, para um usuário doméstico pode ser quase um desastre, — em especial, se “informática” não for sua praia, mas apenas ferramenta, e se lhe coloque o dilema de parar todo o seu trabalho, para procurar alternativas (encontrará?), aprender, refazer rotinas de trabalho, — ou contratar uma consultoria, que não estava prevista no orçamento.

Por isso, a dependência da Canonical já vinha incomodando, — em especial, à vista de reiteradas dissensões com as “comunidades”, divergências de rumos etc.

Um breve resumo foi dado por Swapnil Bhartiya, em “6 things Mark Shuttleworth should do as CEO of Canonical”:

Canonical e Shuttleworth têm uma longa história de membros perturbadores da comunidade de código aberto:
  • o Unity foi criado porque a Canonical não podia trabalhar com o Gnome;
  • Banshee foi expulso do Ubuntu porque a Canonical queria fazer um corte de vendas;
  • Houve uma disputa entre Canonical e Linux Mint sobre taxas de licença;
  • O fundador do Kubuntu foi expulso de seu próprio projeto;
  • Houve uma batalha desagradável dentro da comunidade Debian sobre o uso de systemd vs Upstart;
  • Mir foi anunciado com críticas pesadas das comunidades Wayland e Xorg.
Você pode ver que há uma lista muito longa de confrontos entre a Canonical e outras comunidades de código aberto.

No original:

Give respect to earn it: You can’t expect a community to include features that you need if you are not seen as a good citizen. Canonical and Shuttleworth have a long history of upsetting members of the open source community: Unity was created because Canonical couldn’t work with Gnome; Banshee was kicked out of Ubuntu because Canonical wanted to take a cut of sales; there was a dispute between Canonical and Linux Mint over licence fees; the founder of Kubuntu was kicked out of his own project; there was a nasty battle within the Debian community over the use of systemd vs Upstart; Mir was announced with heavy criticism from the Wayland and Xorg communities. You can see there is a very long list of confrontations between Canonical and other open source communities.

Naturalmente, são receios de usuário apenas familiarizado com o básico, — que não afetam experts capazes de montar e desmontar seu próprio Linux em maior ou menor grau.

Histórico


Funcionalidades já obtidas (pessoalmente), com diferentes sistemas Linux instalados

Durante vários anos, congelei o velho Windows XP e investi no Linux, até conseguir realizar todo o trabalho no Kubuntu e no Linux Mint (não no Debian), e essas 2 ferramentas implicavam na dependência de “decisões proprietárias” da Canonical.

Como essas, anunciadas agora, — ou as decisões anteriores, agora abandonadas de súbito.

O surgimento do KDE Neon, — fora do controle direto da Canonical, — acena com alguma perspectiva de independência, como se viu na adoção do Calamares, em Janeiro de 2017. Permite sonhar que nem todas as “decisões proprietárias”, que a Canonical possa adotar, venham a ser passivamente repassadas ao usuário do KDE Neon.

Mas, para quem, após 10 anos, ainda não conseguiu domar o Debian, é auspicioso conseguir bons resultados com o Mageia 6 sta2 e com o openSUSE, — praticamente “de fábrica”, dado meu despreparo para alterar muita coisa, — sem interromper o trabalho (nem a diversão) para mergulhar em estudos aprofundados da estrutura do Linux.

WTF Canonical?


Não engatinhei nem aprendi a andar em inglês. — Tampouco, jamais aprendi coisa alguma, lendo “definições”. — E parece que apenas sigo o mundo, onde “manuais” conceituais acabaram substituídos por “métodos” realistas (exceto no portal Debian).

Empresas passam, fica a humanidade, — o lápis, o papel, o alfabeto, felizmente (ainda) livres de copyright, licenças, juramentos de fidelidade às imposições “patrióticas” do Department of Commerce. Patrióticas de quem, cara-pálida?

De um ponto de vista muito pessoal, — ou deveríamos dizer, “muito profissional?, — “Canonical” é apenas o “X” de uma questão “Canonical vs. Redirets”. E deixemos de lado o “direito canônico”, que aqui não vem ao caso.

Durante muitos anos, li dizer que a Canonical teria impulsionado a expansão, difusão e aceitação do Linux dappertutto, — nem vou negar, credo quia absurdum, — e, até mesmo, que o Debian (esse “ingrato”) lhe deveria algo por isso.

Olhando apenas o “interesse” (consultas), ao longo dos anos, — e lembrando que, “lá no início” (do Distrowatch, 2002) mantinham-se no topo Mandrake (1º), Red Hat (2º), Gentoo (3º), Debian (4º), SuSE (6º), Slackware (7º), — o Debian (agora em 2º) tinha pouco a ganhar. Mas, por mérito de quem?

Com certeza, não dá para atribuir à Canonical as atuais posições do openSUSE (4º), Fedora (6º) + CentOS (9º), Mageia (12º), — muito menos as do Arch (10º) + Manjaro (5º) + Antergos (16º). — A própria “queda” do Slackware (17º), seria bem menor, caso todos os “derivados” Ubuntu fossem agrupados no 1º lugar, liberando posições no ranking.

Na verdade, deveríamos atribuir ao Ubuntu (3º) a posição do Mint (1º), — e eliminar do ranking dúzias de “sabores” e “derivados” do Ubuntu (Zorin 7º, Deepin 11º, Elementary 8º, Ubuntu MATE 14º, LXLE 18º, Lite 19º, Lubuntu 20º etc.).

É verdade que isso jogaria o Ubuntu, — somados “sabores” e “derivados”, — disparado, no topo do mundo, bem acima do Mint (1º). Aliás, o Mint desapareceria, somado ao Ubuntu.

Mas, feito esse expurgo, — e somados, igualmente, Manjaro + Arch + Antergos, por exemplo, — ficaria muito complicado pretender que o Debian devesse tanto ao Ubuntu.

Ali estariam, de um modo geral, os velhos “troncos”, — além do Arch, mais “novo” (e do Slackware, que subiria bastante), — e dificilmente se poderia pretender que apenas o Debian devesse ao paternalismo da Canonical sua persistência no topo, com os demais “troncos”.

— … • … —

Não-debians


quarta-feira, 15 de março de 2017

Montagem de partições no Antergos e no Manjaro

Antergos uptime 1min2 0seg, com 25 partições adicionais montadas automaticamente

A montagem automática das partições “adicionais”, — aquelas que não fazem parte do “sistema”, — foi um dos fatores a retardar o relato da instalação e configuração do Antergos, em 3 Mar. 2017.

Com todas as capturas de tela centralizadas na partição “XTudo”, — pois não faria sentido deixá-las dispersas nas partições dos 11 sistemas instalados em paralelo, — a boa ordem dos trabalhos pressupõe que essa partição “XTudo” esteja montada desde o momento em que cada sistema é carregado, para registrar o tempo decorrido (uptime), o uso inicial da Memória RAM, e vários outros indicadores exibidos no Conky.

Desde o início de cada sessão, o Dolphin também já deve estar aberto, — com várias abas, em várias pastas, conforme os trabalhos em andamento, em cada época. — Essas “flutuações” do ambiente de produção são atualizadas pelo recurso “Desligar / Sessão → Salvar sessão”, aliado à opção de “Restaurar a sessão salva manualmente”.

Este relato se compõe dos seguintes resumos, — com links para mais detalhes de cada caso:

  • Manjaro
  • Udisks2
  • Polkit-1
  • Antecedentes
  • Linux Mint 17.3 Cinnamon
  • Debian 8 / 9
  • openSUSE
  • Fedora
  • Sabayon

Manjaro


Montagem automática de partições “adicionais” pelas Configurações de sistema do Manjaro KDE

Curiosamente, essa montagem automática não tinha apresentado problema algum no Manjaro (1º Jan. 2017), — também baseado no Arch Linux. — Bastou marcar as partições “adicionais” nas Configurações do sistema (KDE), e desde então, elas são automaticamente montadas no início de cada sessão.

Nesse aspecto, o Manjaro se comportou exatamente como o Kubuntu, o KDE Neon e o Linux Mint KDE, entre outros, — nos quais, basta isso, para obter a montagem automática.

Udisks2


Uso do daemon udisks2 na montagem automática de partições “adicionais”

Por trás dessa configuração, “trabalha” o daemon udisks2, — o mesmo utilizado pelo Dolphin, por exemplo, para montar uma partição “sob demanda” (quando você clica nela, no Dolphin).

Por isso, o caminho (path) para a montagem da partição é igual nos 2 casos, — e pode ser alterado por algumas regras em “/etc/udev/rules.d/”:

/etc/udev/rules.d/99-udisks2.rules


# UDISKS_FILESYSTEM_SHARED
# ==1: mount filesystem to a shared directory (/media/VolumeName)
# ==0: mount filesystem to a private directory (/run/media/$USER/VolumeName)
# See udisks(8)
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{UDISKS_FILESYSTEM_SHARED}="1"

Polkit


Criação do arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” no Antergos

Acontece que, no Antergos, ao clicar no Dolphin para montar uma partição exibida na barra lateral, ele solicita a senha de Root, — coisa que não acontece durante o carregamento do sistema, — e o resultado é como um carregamento “incompleto”, pendente de ação manual (senha de Root), antes que o ambiente se possa considerar realmente pronto.

Em resumo, a mera configuração de montagem automática não funcionou no Antergos.

Por comodismo, talvez o próximo passo fosse tentar o arquivo “/etc/fstab”, — mas não encontrei nos repositórios nenhum aplicativo similar ao “Discos” (gnome-disk-manager), nem ao “Gerenciador de discos” do Debian. — Ou, se encontrei, não consegui perceber, ou ter certeza. Em Arch, sou estranho em terra estranha.

Sem entender absolutamente nada desse emaranhado de sutilezas que é a estrutura de um Linux, — e por isso, dando apenas 1 passo de cada vez, para sentir o terreno, — comecei por testar uma alteração de “política”, que já havia resolvido um problema semelhante no Fedora.

Em resumo, tratava-se de criar o arquivo “/etc/polkit-1/rules.d/99-udisks2.rules”, e colar nele o conteúdo sugerido, — para habilitar a montagem de partições sem a exigência da senha de Root:

// Allow udisks2 to mount devices without authentication
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.filesystem-mount-system" || action.id == "org.freedesktop.udisks2.filesystem-mount" || action.id == "org.freedesktop.udisks2.filesystem-mount-system-internal") { return polkit.Result.YES; } });

Sequência repetida a posteriori, para conferir como foi criado o arquivo “99-udisks2.rules

Na falta de um recurso tipo “Dolphin como Root”, foi seguida a sequência:

su
cd /etc/polkit-1/rules.d
kate
[copy & paste]
save as
99-udisks2.rules

Um pouco mais à vontade com comandos em tela preta, seria mais simples apenas copiar esse arquivo do Fedora.

Antecedentes


Sistemas Linux experimentados nos primeiros 8 anos

Instalar e usar um sistema Linux “facilitado” para iniciantes, — como o (K)Ubuntu, — exige muito pouco aprendizado.

Até o início de 2016, — embora usando Linux desde 2007, — havia aprendido o mínimo. Acessar e gravar nas partições “E:\” e “F:\” do Windows era tudo quanto bastava, — não importando se o Dolphin as apresentava como “Volume de 178 GB”, pois eram poucas; dava para identificar. As partições nem tinham rótulos (label), e ignoro como eram os pontos de montagem.

O fato daquelas partições usarem sistema de arquivos Fat32, — sem manhas de “proprietário” ou “permissões”, — pode ter facilitado seu uso simplificado, dispensando maior estudo.

A mera instalação / configuração de 1 novo Kubuntu LTS a cada 2 anos tampouco estimulava maior aprofundamento, — bastava recuperar as funcionalidades habituais (ou substituir alguma que desaparecia). — Manter o velho Windows também facilitava a acomodação.

Encontrava pouco tempo para dedicar ao “segundo” Linux, — não lembro, sequer, como fiz para obter (se é que obtive) a montagem automática de partições “adicionais” em antigas instalações do Debian e do Linux Mint. — Claro, existem cadernos com anotações, mas além de não oferecerem “CTRL-F”, só registram algumas soluções que pareciam mais valiosas. O que foi fácil ou não foi conseguido, não ficou anotado. E o que demorava a ser conseguido, só era anotado quando boa parte do histórico já estava esquecido.

Apenas a partir de Mar. 2015, com a instalação de um segundo Kubuntu, — “igual” ao primeiro, exceto por ser 32-bit, ao invés de 64-bit, — as configurações começaram a ser sistematizadas, com registros mais completos e detalhados.

A bem dizer, 99% do pouco que sei foi aprendido nesses últimos 12 ou 14 meses, “brincando” de instalar 2, depois 4, e agora 11 sistemas “em paralelo” (multiboot), — com o propósito firme de substituir todas as tarefas ainda dependentes do Windows, — e procurando registrar com detalhes, aqui no Byteria, em postagens um pouco mais estruturadas.

Portanto, os “antecedentes” (abaixo) são meras observações, — com algumas “receitas” práticas, que podem não ser as mais indicadas. — Mero registro, acompanhando um aprendizado ainda bastante precário.

Estudar a estrutura completa do Linux, — caminho para de fato conhecê-lo, — ainda é coisa para o futuro.

Mint Cinnamon


Comandos adotados para montagem automática de partições no antigo Linux Mint 17.3, no início de 2016

Acostumado unicamente ao KDE (Kubuntu), a montagem automática de partições “adicionais” foi particularmente espinhosa no Linux Mint 17.3 Cinnamon (Jan./Fev. 2016), — cujo “Discos” (gnome-disk-utility) escrevia o “/etc/fstab” para usar um recurso do x-gvfs-show ainda incompatível com o resto do sistema (util-linux 2.20).

Disposto a evitar o “/etc/fstab”, — e em especial, evitar escrevê-lo “manualmente”, — a solução adotada acabou sendo a inserção de comandos udisks em “Menu → Preferências → Aplicativos de sessão (gnome-session-properties) → Adicionar → Comando personalizado”:

udisksctl mount --block-device /dev/disk/by-uuid/<uuid>

Debian


Edição do arquivo “/etc/fstab” pelo Gerenciador de discos.(Disk Manager 1.1.1)

O registro detalhado da pesquisa para a montagem automática de partições “adicionais” no Linux Mint 17.3 Cinnamon facilitou bastante a escolha da solução adotada no Debian testing “Stretch”, poucos meses depois, em Jun. 2016.

Embora resistisse ao uso do arquivo “/etc/fstab”, o Gerenciador de discos.(Disk Manager 1.1.1) se mostrou tão eficiente e prático para editá-lo, que a pesquisa parou ali mesmo, — sem chegar à “polkit”, por exemplo, que por isso, nem sei como funciona (ou se funciona) no Debian.

Em resumo, o Gerenciador de discos permite, facilmente, habilitar a montagem automática de partições escolhidas, — além de editar o caminho (path) ou ponto de montagem, e mais alguns parâmetros básicos.

Um parâmetro inicialmente adotado para a montagem da partição “F:\” (Fat32), — verificar o sistema de arquivos a cada 30 sessões, — acabou resultando numa demora de mais de 1 minuto, no carregamento de todas as sessões do Debian, caso tivesse passado pelo Linux Mint 17.3 Cinnamon.

O mais provável é que o Linux Mint 17.3 guardasse alguma configuração (manual) heterodoxa, feita para compatibilizar com o “relógio de sistema” do antigo Windows XP (eliminado desde Abril), — e isso deixava na partição uma “data de acesso” situada no futuro (do ponto de vista do Debian).

Infelizmente, esse Gerenciador de discos não tem sido encontrado nos repositórios de outras distros. — Não veio com o Debian testing “Stretch” (Jun. 2016), pois foi instalado depois. — Também não veio com o Debian 8.6 (30 Set. 2016), pois o Histórico do Synaptic indica que só foi instalado em 4 Out. 2016. — Continua nos repositórios do Debian testing / Debian 9, porém o desenvolvedor não tem planos de nova versão, e solicita contato de quem queira assumir a tarefa.

openSUSE


Particionador do YaST2 também serve como “editor” do arquivo “/etc/fstab

Tal como no Debian, também no openSUSE (17 Jan. 2017) não adiantou recorrer ao “Menu K → Configurações do sistema → Hardware → Armazenamento removível → Dispositivos removíveis” para obter a montagem adicional de partições “adicionais”.

Embora jamais tivesse visto de longe um SuSE ou openSUSE, encontrar a solução foi relativamente fácil e rápido, — graças às recentes pesquisas para lidar com essa questão no Mint 17.3 Cinnamon (Jan. 2016) e no Debian (Jun. 2016), sistematizadas em registros detalhados.

Em resumo, o “Particionador” do YaST2 supre o mesmo papel do “Discos” e do “Gerenciador de discos”, — editar o arquivo “/etc/fstab”, mediante opções em uma interface gráfica, — porém de um modo bem mais eficiente e detalhado, com riqueza de parâmetros.

30 Mar. 2017 - Encontrada solução para montagem automática de partições adicionais no openSUSE, — e finalmente evitado o uso do “/etc/fstab” para isso.

Fedora


Fedora não carregava mais, após a edição do arquivo “/etc/fstab

O Fedora (31 Jan. 2017) rompeu o dualismo “udisks2” vs. “/etc/fstab”, — nenhum dos dois funcionou, — e finalmente exigiu pesquisar além deles, até descobrir a existência uma “terceira via”.

Descartado o simples recurso ao “udisks2”, a primeira tentativa foi usar o “Gerenciador de partições do KDE” (KDE Partition Manager), — porém ele não consegue montar as partições, por não existirem os pontos de montagem. — Ao que parece, ele não os cria.

Outra tentativa foi instalar e usar o “Discos” (gnome-disk-utility), — encontrado nos repositórios, — para resolver a montagem automática de partições “adicionais”.

Nos 2 casos, a edição efetuada por eles no arquivo “/etc/fstab” deixou o Fedora “incarregável”, — entra em “Emergency mode”, pedindo senha Root para manutenção. — O melhor que se pode fazer, nessa hora, é des-editar o “/etc/fstab”, usando o “vi”, por exemplo.

Ou, criar os pontos de montagem indicados nele, — mas, como ainda não sabia nada disso, o caminho mais simples foi disparar um “reboot” e ir para outro sistema, pesquisar mais.

Encontrada a solução “polkit-1”, finalmente o Fedora carregou normalmente, — com as partições e pontos de montagem indicados no “/etc/fstab”. — Depois disso, (aindanão foi feita nova tentativa com “udisks2”, para ver se agora ele também funcionaria (dispensar a edição do “/etc/fstab).

Sabayon


Copiando “99-udisks2.rules” do Antergos para o Sabayon, no Krusader (modo Root)

17 Mar. 2017 - A montagem automática de 4 partições “adicionais” tinha sido habilitada nas Configurações do sistema (System settings) do Sabayon (4 Mar. 2017), — porém não funcionou.

Para testar o procedimento mais simples, foi agora copiado o arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” do Antergos para o Sabayon, — usando o Krusader (modo Root), — e bastou carregá-lo para confirmar o resultado.

Mageia


Montagem automática de todas as partições habilitadas pelo udisks2, ao carregar o Mageia 6 sta2

A mera configuração de montagem automática pelo “Menu K → System settings → Removable devices” também não produziu qualquer efeito no Mageia 5, — e para agilizar, foi utilizado o Centro de Controle Mageia para definir as partições “adicionais” a serem montadas, — um modo de usar interface gráfica para “escrever” no “/etc/fstab”, sem cometer erros bobos de digitação, depois espremer os olhos e os miolos numa sopa de letrinhas.

Agora, ao substituí-lo pelo Mageia 6 sta2, foi feito o teste de simplesmente copiar o arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” do Antergos, — usando o “Krusader as Root”, — e finalmente os comandos udisks2 definidos pelo pelo “Menu K → System settings → Removable devices” puderam fazer efeito ao iniciar a sessão.

Conclusão


Parece muito provável que a autorização contida em um arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” possa dispensar o uso do “/etc/fstab” também no Debian, no Fedora e no openSUSE, bastando então escolher as partições “adicionais” pelo “Menu K → System settings → Removable devices”.

A experiência ainda não foi feita no Debian, porque a estrutura da pasta “/etc/polkit-1” é um pouco mais complicada, — e bem diferente.— Convém estudar com calma, para não sair mexendo à toa:

localauthority
    10-vendor.d
    20-org.d
    30-site.d
    50-local.d
    90-mandatory.d
localauthority.conf.d
    50-localauthority.conf
    51-debian-sudo.conf
nullbackend.conf.d
    50-nullbackend.conf

Também no Fedora e no openSUSE, vale a pena escolher um momento de calma para colocar toda atenção, ao fazer a experiência de trocar o “/etc/fstab” pelos comandos udisks2 das Configurações do sistema + polkit.

30 Mar. 2017 - Encontrada solução para montagem automática de partições adicionais no openSUSE, — e finalmente evitado o uso do “/etc/fstab” para isso.

— … ≠ • ≠ … —

Não-debians


quinta-feira, 9 de março de 2017

Transição do Manjaro (rolling-release) para 17.0

Manjaro antes e depois do upgrade

Na maior tranquilidade, — sem fanfarra e sem foguete, — quase ia passando desapercebida a transição do Manjaro 16.10.3 para 17.0.1, no dia 6 Mar. 2017.

Ou do release “16.10.1”, conforme o “/var/log/pacman.log”:

[2017-03-06 12:59] [ALPM] upgraded manjaro-release (16.10-1 -> 17.0-1)

Uma “atualização” comum, corriqueira, dessas que se fazem todos os dias, — sem necessidade de avisos, advertências, nem cuidados especiais.

Só no outro dia, — quando o lançamento da nova versão foi noticiado no Distrowatch, — me dei conta de que o Grub* agora indicava “Manjaro 17”, e que no Conky a identificação “Fringilla” foi substituída por “Gellivara”.

* Para simplificar, em momentos mais calmos são carregados e atualizados os vários sistemas Linux, sucessivamente, e por fim é atualizado o Menu de inicialização (Grub), para dar acesso às eventuais mudanças de Kernel. O Manjaro só voltou a ser carregado 2 dias depois mas, embora o Kernel permanecesse o mesmo, o Menu de inicialização refletiu a mudança do título para “Manjaro 17”.

Para um histórico mais abrangente:


Novidades


Notificação de “83 atualizações disponíveis”, no Manjaro. Ação oferecida: “Atualizar sistema”
Notificação de “83 atualizações disponíveis”, no Manjaro. Ação oferecida: “Atualizar sistema”

Em se tratando de uma distribuição rolling-release, talvez não fosse mesmo de esperar música de banda, bandeirolas e foguetório.

E é possível que o upgrade tenha menos a ver com impactos imediatos, — pelo menos, para quem vinha atualizando regularmente o sistema, — e mais com o que virá daqui por diante.

De mais visível, seu KDE evoluiu de 5.9.2 para 5.9.3, — embora várias outras novidades tenham sido anunciadas:

  • We updated the stock kernel to linux49 4.9 LTS
  • We updated the Xorg-Stack to v1.19 series
  • We updated KDE to its latest components: Plasma 5.9.3, Apps 16.12.3, Framework 5.31.0
  • We enhanced and improved our Manjaro Tools & Profiles
  • MHWD we adopted a more efficient way to handle libglx binaries
  • Some of our themes got updated and new got designed

Kernel, à parte


Gerenciamento de Kernel, no Menu K → Configurações → Manjaro settings manager → Kernel

Na prática, nem o Kernel mudou, — pois isso é gerenciado à parte, conforme a opção de cada usuário.

E o fato de o Kernel 4.9 LTS não oferecer “Registro de alterações”, — nem qualquer indicação de “Recomendado”, — não anima um iniciante a mexer com isso, por enquanto. Para que?

Outras novidades anunciadas, também merecem um desconto, — Framework 5.31.0, por exemplo, já estava instalado desde muito antes. — O que de fato mudou, conforme o pacman.log, foi:

[2017-03-06 12:59] [ALPM] upgraded kio (5.31.0-1 -> 5.31.0-2)

Cabe verificar outros pequenos detalhes como esse, — ou apenas ser feliz.

Mensagens de erro


Mensagens de erro no início da atualização

O que de fato chamou atenção, — e talvez a tenha desviado da novidade, — foi uma sucessão de mensagens de erro, acusando falta de resposta do Mirror brasileiro linorg.usp.br (se é que entendi o que se passou), no caso de inúmeros pacotes.

Porém, foi constatado que o Chromium navegava normalmente. — Além disso, muitos outros pacotes foram baixados sem mensagem de erro, — e no final o Octopi emitiu mensagem de “sucesso”, mudando a notificação do Painel, de vermelho para amarelo (só atualizações do AUR).

Para todos os efeitos, portanto, as atualizações se completaram com sucesso.

Com todas as demoras de resposta (ou falta de) por parte do linorg.usp.br, o processo durou 22 minutos, — das 12:37 às 12:59.

Uma recente atualização, de tamanho mais ou menos semelhante (87 pacotes), em 22 Fev. 2017, durou 15 minutos, — das 22:26 às 22:41.

Outra atualização, numericamente bem maior (203 pacotes), em 2 Fev. 2017, durou 13 minutos, — das 11:52 às 12:05.

Prioridade dos Mirrors


Arquivo /etc/pacman.d/mirrorlist, gerado conforme o menor tempo de resposta

Terminada a novela do Mirror, — e sem muita segurança de que a atualização se tivesse completado de modo 100% católico, — procurei um meio de escolher outro Mirror. Mas, não é assim que as coisas funcionam.

O comando “sudo pacman-mirrors -g” sonda todos os Mirrors do mundo, — para o Brasil, só está configurado o da USP, — e atualiza a lista, por ordem crescente do tempo de resposta.

Arquivo “/etc/pacman.d/mirrors/Brasil”:

[Brasil]
Server = http://linorg.usp.br/manjaro/$branch/$repo/$arch

Arquivo “/etc/pacman.d/mirrorlist”:

## Manjaro Linux repository mirrorlist
## Generated on 09 March 2017 16:22
##
## Use pacman-mirrors to modify
##

## Country       : Brasil
## Response time : 0.198
## Last sync     : 18:43h
Server = http://linorg.usp.br/manjaro/stable/$repo/$arch

## Country       : United_States
## Response time : 0.443
## Last sync     : 18:45h
Server = http://mirror.dacentec.com/manjaro/stable/$repo/$arch

## Country       : Ecuador
## Response time : 0.450
## Last sync     : 18:43h
Server = http://mirror.cedia.org.ec/manjaro/stable/$repo/$arch

## Country       : Netherlands
## Response time : 0.482
## Last sync     : 18:44h
Server = http://ftp.nluug.nl/pub/os/Linux/distr/manjaro/stable/$repo/$arch

... (etc.)

xx

— … ≠ • ≠ … —

Não-debians


domingo, 5 de março de 2017

Sabayon (Gentoo) - Instalação e configuração

Sabayon (Gentoo) após “atualização 2 disponíveis”, — que levou 2h 30min, talvez por inexperiência

As principais observações sobre o Sabayon 16.11 KDE (amd64), — no que difere dos demais sistemas Linux já instalados, — referem-se ao gerenciamento de pacotes e atualizações.

Vale notar que esta é uma experiência sem estudo prévio sobre Gentoo ou Sabayon, — trata-se de “aprender fazendo”, — onde mais vale o gosto de “ver” e “brincar”, do que qualquer (suposta) “obrigação”.

  • Essa “brincadeira” (absoluta “falta de pressa”) é possível porque o Kubuntu 16.04 LTS e o Linux Mint 18.1 KDE garantem o “ambiente de produção” para todas as tarefas necessárias. Além deles, o KDE Neon User Edition e o openSuSE também atendem às tarefas mais frequentes no dia-a-dia. — Portanto, basta reiniciar o computador, escolher o sistema da hora, — e mais tarde, voltar ao Sabayon para seguir brincando.

Ainda falta a montagem automática das partições “adicionais”, — e depois, adaptar o “~/.conkyrc” para exibi-las, — uma vez que, no Sabayon, não basta marcá-las em “K Menu → Configurações do sistema → Hardware → Armazenamento removível → Dispositivos removíveis”.

É provável que essa montagem automática se resolva pelo arquivo “/etc/fstab” (como no Debian e no openSuSE), e / ou pela configuração de alguma “política” (“polkit”, como no Fedora).

••• Ver “Montagem automática de partições adicionais” - (adiante).

É claro que houve alguma pesquisa e leitura, — em especial nesses 3 pontos fundamentais:

  • Sua escolha, — porque Sabayon pareceu a melhor opção para a experiência inicial de um leigo, na área do Gentoo.
  • Alguma leitura básica sobre sistema Portage de gerenciamento e instalação de pacotes (Gentoo), e mais especificamente Entropy, equo etc. [Viva o Linux, Sabayon]
  • Confirmar que, — nessa primeira aproximação, — poderia deixar de lado coisas como LVM, BtrFS, XFS etc., além de dispensar qualquer (suposta) necessidade de partição “/boot” separada. — A instalação foi feita unicamente com partições “/” (raiz) e “/home”, — ambas “tradicionais”, em sistema de arquivos ext4, — além de 1 partição Swap.

ISO e Live DVD (I e II)


Mensagem de erro quilométrica, perto do final da 1ª tentativa de instalação do Sabayon

A imagem ISO do Sabayon 16.11 KDE (amd64) foi baixada e verificada por md5sum em 3 Mar. 2017.

Por distração, um primeiro DVD acabou sendo gravado pelo K3b na velocidade 16x (4 Mar. 2017).

Por isso, no Menu de Boot, foi usada a opção “Check disk for defects”, que terminou com uma mensagem positiva, — “All fine, baby, the Live System is healthy”, — apesar de outras mensagens de “No iSCSI initiator found” e de “Sorry, but keyboard mapping br is invalid”.

Depois da verificação, ele reiniciou e foi carregada a sessão Live DVD, — que tratei de configurar ao máximo, além de abrir o navegar no Chrome para tirar algumas dúvidas, antes de iniciar a instalação, — mas nessa 1ª tentativa o processo não se completou.

A fase de instalação, propriamente dita (slide-show), começou às 17:07, e às 17:31 já estava nas “tarefas de configuração de pós-instalação”, — mas às 17:33 apresentou mensagem de erro, com 3 opções (Report bug, Debug, Quit), e foi encerrado.

Durante todo esse tempo, o KSysguard não registrou atividade de rede, — download, — embora o Chrome estivesse conectado e navegando normalmente, — antes, durante e depois da tentativa de instalação.

Para minimizar os riscos de novo erro, foi gravado um segundo DVD em velocidade 4x. — A nova sessão Live DVD foi carregada sem as opções de Idioma e Teclado PT-BR, — e configurada só no mínimo indispensável para as capturas de tela (Atalho “PrtScn”).

Nesta 2ª tentativa, o Instalador foi deixado em full-screen, — evitando abrir o Chrome ou alternar com o Dolphin, — que foi aberto apenas para montar o Pendrive e confirmar a gravação da primeira captura de tela.

A fase de instalação, propriamente (slide-show), começou às 23:00 e foi deixada sozinha, — sem supervisão, sem prints, sem qualquer outra atividade humana. — De acordo com o arquivo “/var/log/anaconda/anaconda.log”, terminou às 23:29, com mensagem de sucesso.

Instalação (II)


Início da 2ª tentativa de instalação do Sabayon, — com o Relógio do Painel “estacionado”, havia 3 minutos

A 2ª tentativa de instalação do Sabayou começou por volta das 22:46, — embora o Relógio do Painel tivesse parado em “22:43” (que continuou exibindo até o final). — No entanto, as capturas de tela (bem como os logs) registram as horas corretas, compatíveis com as das fotos de celular.

O instalador Anaconda, — já conhecido da instalação do Fedora, — é menos “sequencial” do que os instaladores do Debian, do Ubuntu (Ubiquity) ou do Manjaro (Calamares).

Os primeiros passos foram escolher o Idioma e o layout do Teclado (PT-BR), assim como o Fuso horário (Américas / São Paulo).

Opções iniciais da instalação do Sabayon

A conexão (Rede) já tinha sido detectada e ativada automaticamente, desde o carregamento da sessão Live DVD, — mas poderia alterar o nome do Host para “Linux11”, por exemplo.

Neste ponto, restava definir o destino da instalação, — discos, partições etc., — para habilitar o botão “Iniciar a instalação”.

Escolha do dispositivo, — e da opção “Eu irei configurar o particionamento

Tendo previamente confirmado que poderia usar um esquema de particionamento simples e trivial, foi escolhido o dispositivo SSD externo, — e marcada a opção “Eu irei configurar o particionamento”.

Seleção manual de partições pre-existentes, para a instalação do Sabayon

Na 1ª tentativa, me guiei pelas partições do Antergos (Unknown Linux), — somando +1 na numeração de cada partição, — de sdd1 para sdd2 (“/”), de sdd5 para sdd6 (“/home”), de sdd9 para sdd10 (Swap).

Mas poderia ter feito de cabeça, uma vez que as primeiras 3 partições são para sistemas, a 4ª é a partição estendida, as 3 seguintes são para Home, em seguida uma partição de dados (Armazem), e as 3 últimas para Swap, — tudo na devida ordem numérica.

Porém, na 2ª tentativa bastava selecionar as 3 partições da tentativa anterior, — e preencher com os mesmos pontos de montagem. — Cada uma das partições configuradas vai sendo transferida de “Sabayon” (embaixo, à esquerda) para “Novo Sabayon” (no alto).

Resumo do particionamento, — ao clicar em “Finalizado”

Ao clicar em “Finalizado” (no alto, à esquerda), se apresenta o resumo das ações de particionamento que foram definidas pelo usuário. — Se estiver tudo certo, clique em “Aceitar mudanças”.

Voltamos então à tela “Resumo da instalação”, — agora, com o “Destino” definido, — e com o botão “Iniciar a instalação” habilitado, para prosseguir.

Opções avançadas, — em Criar usuário

Então, requisita-se a definição da Senha Root, — e se oferece a oportunidade de Criar usuário, — com as opções de torná-lo Administrador, requerer (ou não) senha para usar a conta de usuário, e mais algumas Opções avançadas.

Início da instalação do Sabayon no computador, — com slide-show

Por fim, a mesma tela, — que requisitou definir Senha Root e ofereceu a oportunidade de Criar usuário, — é aproveitada para o slide-show durante a instalação do Sabayon no computador.

Ao contrário de outros instaladores e “distros”, — por exemplo, Debian, — aqui não será necessária mais nenhuma ação do usuário.

Você pode até ir dormir, — mas a demora não chegou a 30 minutos.

Configurações do sistema (KDE)


Montagem automática de partições (KDE), — sem efeito, até o momento (••• ver adiante)

A primeira sessão do Sabayon instalado começou à 0:05 de 5 Mar. 2017, — seguindo o roteiro comum de configurações personalizadas:

  • Configurar Dolphin. — Montar partição “XTudo”
  • Papel de parede
  • Configurar Spectacle. — Inverter atalhos PrintScreen / Shift-Print
  • Na inicialização, restaurar sessão salva manualmente. — Salvar sessão
  • Ativar NumLock ao iniciar o KDE Plasma. — Tecla de acesso ao terceiro nível
  • Montagem automática de partições adicionais
  • Desativar a Carteira do KDE (KWallet)
  • Login automático. — Entrar novamente após sair (“Encerrar sessão”)
  • Temas da área de trabalho → obter → Maia transparent
  • Decorações da janela → obter → Transparent oxygen
  • Bloqueio de tela — Não bloquear após X minutos. — Não bloquear ao reativar
  • Efeitos da área de trabalho → Cubo
  • Pesquisa de arquivos — desativar
  • Compositor — (Automaticamente escolhido: OpenGL 2.0; Método de escala: Preciso)
  • Efeitos da área de trabalho — Desativadas animações ao Minimizar / Maximizar etc.

A montagem da partição “XTudo”, — onde costumam ficar fotos, capturas de tela, modelos do Conky e todo material mais usado nessas experiências, — pediu senha Root, por isso, foi deixada para depois.

Não havia pressa. Todo esse material tem cópia no 2º backup, — na partição “Armazem2”, do SSD externo, — que não precisa de senha para montar. Por algum motivo, basta clicar nela, pelo Dolphin.

O capítulo de montagem automática de partições “adicionais”, nas Configurações do sistema (KDE), não faz efeito algum, — tal como não faz efeito no Debian e mais algumas “distros”. — Provavelmente, será necessário incluí-las no arquivo “/etc/fstab”, e / ou alterar alguma “política” (tipo “polkit”). Nada muito urgente.

••• Ver “Montagem automática de partições adicionais” (adiante).

As Configurações do sistema (KDE), parece que simplesmente não incluem o Kwallet, — um popup torra a paciência, 2 vezes, a cada vez que se abre o Chrome / Chromium. — Também não é tão urgente.

Também não adiante desmarcar o pedido de senha para logar automaticamente na conta do Usuário, — isso terá de ser resolvido em outro lugar. — Sem urgência.

Enfim, a brincadeira do Cubo foi descartada, — devido a algumas “tremidas nervosas” da tela, nas primeiras horas. — Em vez de sobrecarregar, a opção foi desativar mais alguns “Efeitos” bobos, como as animações de Maximizar e Minimizar janelas. Esse tem sido um cuidado corriqueiro, uma vez que não existe placa aceleradora de vídeo (3D), mas apenas o recurso onboard de 2008, para o qual estão alocados 256 MB da Memória RAM. Após quase 24 horas de uso constante, as coisas parecem bastante tranquilas.

Pacotes e atualizações


Sistema “atualizado”, desde o primeiro momento, — e sem novidades após 1 hora, 2 horas

Chamou atenção o fato de, ao carregar pela primeira vez, logo após a instalação, o Magneto Entropy se apressou em notificar que, — “Seu Sabayon está atualizado. Tudo parece estar Ok. Não há atualizações a fazer. Legal!”.

A versão instalada era “16.11” (29 Out. 2016), — que até hoje (6 Mar. 2017) é a opção-padrão na página de download para desktop, — embora já existam imagens ISO mensais “17.03” (28 Fev.), e imagens diárias com a data de hoje (6 Mar.).

As indicações do Centro de Informações do KDE (KInfocenter) também pareciam defasadas, em comparação com o pouco que havia lido, e com o que diz sua página oficial: — “Sabayon is a beginner-friendly Gentoo-based open-source Linux distribution. We aim to deliver the best "out of the box" user experience by providing the latest open source technologies in an elegant format. In Sabayon everything should just work. We offer a bleeding edge operating system that is both stable and reliable”.

Porém, o mais urgente era instalar o Gimp (que não veio junto), — e substituir o Google Chrome (que veio) pelo legítimo Chromium, para ver se eliminava alguns defeitos iniciais.

No entanto, a (pouquíssima) leitura não deu nem para o começo. Digitando “pacote” ou “Software” no Menu, não se acha nada. Digitando “Package”, aparece apenas um link “Sabayon packages”, — que leva à página “Sabayon Entropy Store”. — Não era bem isso que o iniciante procurava.

Sem saber o “nome de batismo” do gerenciador “Rigo”, — ou as palavras-chave “Application Browser”, — poderia passar por ele vezes seguidas, sem “ver” que ele existia.

Comando “equo update” finalmente encontrou novidades, — e revelou a existência do Rigo

De volta a uma das (pouquíssimas) leituras anteriores, tratei de ouvir um palpite “da boca do cavalo”, como se diz, — e ele mandou apostar em “su” + “equo update”.

Desse modo, — após 2 horas, — finalmente, apareceram “2 atualizações disponíveis”, — e fiquei sabendo da existência do Rigo, com um botão de brinde para abri-lo sem necessidade de voltar ao Menu K.

Por “2 atualizações disponíveis”, — coisa de aparência boba, — leia-se, “1 upgrade completo”.

O processo se estendeu por 2h 25min, — até 4:31, — com dúzias de informações e perguntas muito boas, porém absolutamente incompreensíveis para um iniciante que faltou a 99,7% das aulas.

Ou talvez seja mais exato dizer que terminou às 4:12, — e daí por diante devia ter ignorado o resto?

Rigo “trabalhando muito”, após quase 2 horas, — “Instalando versão 17.03

Depois de quase 2 horas vendo o desfile no “Mostre para mim” do Rigo, — cuja barra de título exibia “Estou trabalhando muito”, — às 3:59 ficou claro que o Sabayon 16.11 estava se transformando em 17.03.

Na verdade, não é possível dizer se fiquei mesmo assistindo esse desfile. Há uma lacuna de 1h25min nas capturas de tela, entre 2:29 e 3:56. Poderia ter havido alguma falha do KDE Spectacle ou da tecla PrtScn, porém é muito provável que tenha ido tirar um cochilo. Afinal, não sabia o que estava fazendo na frente do computador, — e desconfiava que ele saberia cumprir o seu dever, sem ninguém para atrapalhar. Terá feito perguntas? Respondeu sozinho?

Logo adiante, às 4:08, — instalando o Kernel “Linux Sabayon 4.8.17-0”, — reclamou que não conseguiu montar uma penca de partições, mas só pediu a senha depois. Após fornecer a senha, tornou a reclamar que não conseguiu montar a mesma penca de partições, às 4:09.

Atualização completa, — e inúmeros itens para “revisão manual”

A partir das 4:12, a atualização se declarou concluída.

Porém, começaram as perguntas realmente embaraçosas, — bem como vários cliques em “Atualizar” aqui e ali, — e que voltavam a ser exibidos para clicar de novo, várias vezes.

Havia até um trecho, — totalmente em branco (cinza), sem nenhuma pergunta ou informação, — e as opções de “Ok, obrigado!” e “Mostre para mim”. Talvez fosse uma mensagem secreta, com tinta invisível.

Tudo, ao mesmo tempo, — e muitas vezes, sem possibilidade de efeito imediato, — apenas entrar na fila (qeue).

Complicado, por exemplo, dizer que “há 53 bibliotecas preservadas”, — com a opção “Atualizar”, que não faz sentido em nenhuma língua do mundo. — Se foram “preservadas”, é porque não fazem mal. E afinal, tudo já foi “atualizado”. Significaria “remover”?

Enfim, uma gorda fila de aplicativos que “não serão mais atualizados” foi apresentada para “revisão manual”. — Até olhei os primeiros, sem entender nada daquela algaravia. — A decisão acabou sendo a de remover tudo aquilo, — lamentando ficar sem Konqueror e Okular (difícil crer que tenham encerrado suas carreiras). Mas foi uma alegria, quando chegou a hora de eliminar Akonadi, KDE-PIM e várias outras coisas.

Final da “revisão manual”, após a atualização (ou upgrade) do Sabayon

Às 4:31 (relógio exibindo “4:21”), restava apenas o Akonadi para “revisar manualmente”, — declarando no texto (no alto) que você pode “mantê-los ou desinstalá-los”, mas oferecendo (embaixo) “Reinstalar” ou “Remover”, — e as últimas 5 bibliotecas “preservadas”, com aquela opção esquisita de “atualizar”.

A ambiguidade, — afinal, é “manter” ou “reinstalar”?, — aliada à persistência de “avisos” cobrando providência, — pelo menos foi eliminada.

A expectativa é que, — feita a limpeza até o último grão de poeira, — seja possível instalar (sem ambiguidade) o Konqueror e o Okular, — um de cada vez, — e ver se explode, pega fogo, ou assobia.

Mas o mais urgente, ali mesmo, era instalar Gimp, Conky, Xsane, — além de remover o Google Chrome, e instalar o Chromium, — coisas realizadas com sucesso até 4:48 (com o relógio ainda exibindo “4:21”).

Epílogos


Instalação do Konqueror no Sabayon, pelo Rigo Application Browser

6 Mar. 2017 - Concluído o relato (acima), foram reinstalados o Konqueror e o Okular, sem maiores protestos por parte do Sabayon.

Apresentação de dependências adicionais, durante a instalação do Konqueror pelo Rigo, no Sabayon

Ao longo do processo, o Rigo apresenta eventuais dependências, — que podem ser aceitas em bloco, ou examinadas individualmente.

Alteração do hostname, — de “sabayon.local” para “Linux11”

O “nome da máquina” foi corrigido, — de “sabayon.local” para “Linux11”, — pela simples edição do arquivo “/etc/hostname”.

Em outros sistemas, foi necessário editar também “/etc/hosts”, para incluir o novo hostname, — porém no Sabayon o arquivo estava vazio, — e assim foi deixado.

Ao carregar novamente, a mudança fez efeito, e não houve reclamações.

Como não existe rede por aqui, — é um computador isolado, e sem acesso externo, — a utilidade dessa modificação é apenas cosmética, — exibir “Linux11” no Conky e no Konsole.

••• Montagem automática de partições adicionais


Copiando “/etc/polkit-1/rules.d/99-udisks2.rules” do Antergos para o Sabayon, no Krusader (modo Root)

17 Mar. 2017 - Ao resumir a montagem automática de partições “adicionais” nos diferentes Linux instalados, foi retomada esta configuração específica do Sabayon, — aproveitando para testar uma ideia: — Simplesmente copiar e colar o arquivo “/etc/polkit-1/rules.d/99-udisks2.rules” de outro sistema para o Sabayon.

Isso foi feito “de fora”, — no Kubuntu, usando o Krusader em modo Root, para agilizar. — E o Sabayon finalmente carregou com 4 partições “adicionais” montadas automaticamente.

São as partições “Armazem1”, “XTudo”, “Works” e “Sites”, que tinham sido habilitadas nas Configurações do sistema (System settings) desde o dia da instalação do Sabayon, — sem resultado.

Confirmado que agora a configuração funciona, foi habilitada a montagem automática das demais partições.
_________
Relato produzido e publicado de 5 a 6 Mar. 2017, e complementado de 6 a 8 Mar. 2017, no Sabayon.
••• “Montagem automática de partições adicionais” acrescentado em 17 Mar. 2017.

— … ≠ • ≠ … —

Não-debians


segunda-feira, 27 de fevereiro de 2017

Quadro comparativo dos sistemas Linux instalados

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.

Em 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. — 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.


Resumo dos “não-debian”



24 Fev. 2017


Quadro comparativo dos sistemas Linux instalados, com algumas diferenças de funcionalidade
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 começar pelo TrueOS (antigo PC-BSD), — mas a brincadeira dá sinais de saturação.

Mageia, — 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 nem começou.

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 TrueOS (ex-PC-BSD), — afinal, o Debian testing e o KDE Neon (entre outros) são mais do que suficientes para acompanhar a maior parte das surpresas que possam vir nos próximos Kubuntu.

Por fim, o Linux Mint, — único (exceto Kubuntu LTS), em que consigo realizar todas as tarefas necessárias, — sofreu sequelas no upgrade do 18 “Sarah” para 18.1 “Serena”. Continua fazendo tudo, porém com uso excessivo de CPU (e consequente 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? 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.

  • 1º Mar. 2017 - Foi reinstalado o Linux Mint 18.1 KDE, sem formatar a partição-raiz, e o problema continuou.
  • 8 Mar. 2017 - O problema se resolveu sozinho, após uma atualização “com erro”.

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, em dual-boot ou 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, — uma 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, até o final de 2016, de qualquer sistema que não fosse “derivado” do Debian.

Escolha dos “não-debian”


Sistemas Linux escolhidos entre os mais procurados no Distrowatch
Sistemas Linux escolhidos entre os mais procurados no Distrowatch

A ideia era selecionar sistemas de diferentes “troncos principais”, — mesmo que “derivados”, — de modo a 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 () 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 () 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 () 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.

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.

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 examinados em sessões Live CD / DVD, — em parte, por seus ambientes, — e descartados, por falta de interesse pessoal.

Histórico


Quadro comparativo dos sistemas Linux instalados, em 6 Fev. 2017

xx

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

xx

xx

— … ≠ • ≠ … —

Não-debians