Translate

Mostrando postagens com marcador LTS. Mostrar todas as postagens
Mostrando postagens com marcador LTS. Mostrar todas as postagens

sexta-feira, 26 de agosto de 2016

Política de Kernel do Mint vs. Ubuntu, Neon & Debian

Atualização de Kernel disponível, segundo o “mintUpdate”. — E no Painel: — “Seu sistema está atualizado”

Quando um “notificador de atualizações” exibia aviso no Painel, geralmente dava uma olhada rápida*, — depois abria o Synaptic, para conferir os detalhes, “marcar” para instalação, e “aplicar”.

* Até 2 anos atrás, costumava desativar esses “Notificadores”. — O hábito era abrir o Synaptic (quase) todo dia, pela manhã, para verificar e aplicar as “atualizações”, — o que tornava desnecessárias as “notificações” (às vezes meio neuróticas) no meio das atividades diárias.

Muitas vezes, o “notificador” mostra 1 item, — e no Synaptic você descobre que, na verdade, trata-se de vários pacotes.

Você olha o “nome” do conjunto, no “notificador”; — depois, vê os componentes e suas descrições, no Synaptic. — Pode ser muito instrutivo, a respeito do Linux.

O que nunca tinha visto, é o contrário, — um “Gerenciador de atualizações” (mintUpdate) indicar 1 “atualização”, — e o Synaptic (ou o “apt”), nenhuma.

Nenhuma atualização, segundo o “apt”

20 Ago. 2016 - No caso, o mintUpdate indicava a disponibilidade de um novo Kernel, — porém, o comando “sudo apt update”, — disparado 1 minuto depois*, — não encontrou qualquer “atualização”.

* Disparar o comando “sudo apt update” — antes de abrir o Synaptic — é hábito mais recente, para acompanhar eventuais falhas de repositórios, e documentar algumas atualizações (KDE, Kernel etc.).

O Synaptic, — aberto em seguida, — também não encontrou nenhuma “atualização”.

Esse Kernel “4.4.0-34.53” estava lá, nos repositórios, mas só pôde ser localizado aos pedaços, pela busca do Synaptic: — “linux-headers”, “linux-image” etc., — entre milhares de softwares “não-instalados”, só isso.

O alerta de “atualização” permaneceu no Painel das 10:21 até 16:49, — depois, sumiu

Faz todo sentido, — pelo menos, no Ubuntu e seus “derivados”, — embora, até então, nunca tivesse olhado por esse ângulo.

A rigor, uma nova versão do Kernel, — o “núcleo” (cerne) do GNU/Linux, — não é uma “atualização”.

No Ubuntu e “derivados”, ela não vem “substituir” a versão anterior. — Apenas, instala-se mais um Kernel, — e acrescenta-se mais uma opção de carregamento, no Menu de inicialização.

  • O mintUpdate manteve o aviso de “atualizações” no Painel, das 10:21 até 16:49, — embora às 11:29 o Synaptic tenha feito a atualização geral (exceto Kernel). — Constata-se que o mintUpdate não detecta que o Synaptic (já) atualizou tudo: — É preciso reabrir o mintUpdate e “recarregar” as informações, para (só então) ele perceber que não há mais “atualizações” pendentes. — Feito isso, a notificação desapareceu do painel, — embora ainda faltasse instalar (ou não) o novo Kernel — coisa que só foi feita uns 15 minutos depois. — Observa-se, ainda, que o Histórico do Synaptic inclui a instalação e desinstalação de Kernel pelo mintUpdate, — e que não aparecem no Histórico do próprio mintUpdate.

Opções avançadas do Mint 18 no Grub em 21 Ago. 2016, — ainda com Kernel “herdado” do Mint 17.3

Naturalmente, o último Kernel torna-se a opção-padrão de carregamento daquele Ubuntu (ou “derivado”), — e os anteriores acumulam-se nas “Opções avançadas” do Menu de inicialização.

A lógica por trás disso é que, — se seu sistema apresentar problemas com o novo Kernel, — basta reiniciar o computador, entrar nas “Opções avançadas” do Menu de inicialização, e carregar o sistema com o Kernel anterior.

Uma vez “rodando” o Kernel anterior, você pode desinstalar o Kernel mais novo, — com toda segurança, — da mesma forma como, rodando o último Kernel, pode desinstalar qualquer outro Kernel mais antigo.

Download e instalação do novo Kernel pelo mintUpdate, a partir das 17:11

20 Ago. 2016 - Naquele momento, a decisão foi de instalar o novo Kernel, — sem pensar 2 vezes, — como sempre foi feito no Kubuntu, desde 2009, — porém o Synaptic “alterado” do Linux Mint não era a ferramenta adequada.

Não tinha cabimento, o heroísmo de selecionar no olhômetro os 4 pacotes que costumam compor cada novo Kernel.

É muito fácil localizar no Synaptic o pacote “linux-headers-4.4.0-34-53”, bem como o “linux-headers-4.4.0-34-53-generic”, o “linux-image-4.4.0-34-53-generic”, e o “linux-image-extra-4.4.0-34-53-generic”, — mas o processo envolve vários outros arquivos e configurações básicas do sistema, com os quais não se sabe se o Synaptic “amputado” saberia lidar. — Não faz sentido caçar sarna para se coçar.

Era bem mais simples (e seguro) voltar ao mintUpdate e deixá-lo cuidar dessa instalação, — de modo automático, e sem falhas humanas.

Nenhuma “atualização” de Kernel no Linux Mint 17.3, de Janeiro até Agosto

22 Ago. 2016 - Dias depois, — aproveitando que o Synaptic manteve todo o Histórico desde 19 Jan. 2016 (ver “Heranças do Mint 17.3”, na instalação do Linux Mint 18 KDE Beta), — foi feita uma busca, e constatado que, durante 7 meses, não foi oferecido (nem instalado) nenhum novo Kernel.

Essa opção vinha desativada? — Teria desativado por distração?

Os registros da primeira sessão após a instalação do Linux Mint 17.3 Cinnamon, na noite de 18 para 19 Jan. 2016, mostram que o mintUpdate, — sem qualquer mudança das configurações iniciais*, — apresentou e instalou pelo menos 140 dos 146 pacotes “atualizáveis” apontados pelo Synaptic, — e provavelmente também os 6 restantes.

Porém, não apresentou nenhuma “atualização” de Kernel, — que o Synaptic “alterado” pelo Linux Mint tampouco detectou, nos 7 meses seguintes.

* Uma hipótese de o mintUpdate não estar “default”, — ao ser aberto pela primeira vez, após a instalação do Linux Mint 17.3, — seria alguma “herança” de antigas instalações. — Porém não se encontra nada com o nome de “mintupdate” nos arquivos ocultos da “/home”, — e naquela instalação a partição do sistema tinha sido formatada.

Opção “Marcar todas as atualizações” e indicativo de Kernel “auto-removível”, no Kubuntu, Neon e Debian KDE

Seja como for, essas “constatações” já oferecem uma pista para os possíveis motivos de o Synaptic ter algumas de suas características fundamentais “podadas” pelo Linux Mint:

  • Sem o tradicional botão “Marcar todas as atualizações”
  • Sem indicação ou mecanismo para “atualização” de Kernel
  • Sem indicação ou mecanismo para “remoção” de Kernel

Hipótese: — Para evitar que o Synaptic, — em sua configuração plena, — interfira nessa “personalização” introduzida pelo Linux Mint, com sua “política de Kernel” comandada pelo mintUpdate..

Bicho papão?


Não, que migrar para novos Kernel seja esse bicho-papão todo, para a imensa maioria dos computadores comuns, — ou, a substituição frequente de Kernel não seria tão banal nos sabores oficiais do Ubuntu, — de longe, a distribuição mais popular, e explicitamente voltada para usuários leigos.

Atualizações do Kernel no Kubuntu 16.04 desde 24 Abr. 2016, — apenas 5 meses, — no Histórico do Synaptic:

  • 6 May 2016 (18:50) → (4.4.0.21.22) to 4.4.0.22.23
  • 10 Jun 2016 (06:19) → (4.4.0.22.23) to 4.4.0.24.25
  • 27 Jun 2016 (17:04) → (4.4.0.24.25) to 4.4.0.28.30
  • 14 Jul 2016 (20:26) → (4.4.0.28.30) to 4.4.0.31.33
  • 8 Aug 2016 (18:58) → (4.4.0.31.33) to 4.4.0.34.36
  • 31 Aug 2016 (07:30) → (4.4.0.34.36) to 4.4.0.36.38
  • 19 Sep 2016 (13:36) → (4.4.0.36.38) to 4.4.0.38.40

Atualizações do Kernel no KDE Neon desde 31 Mai. 2016, — apenas 4 meses, — no Histórico do Synaptic:

  • 10 Jun 2016 (07:18) → (4.4.0.22.23) to 4.4.0.24.25
  • 28 Jun 2016 (23:22) → (4.4.0.24.25) to 4.4.0.28.30
  • 14 Jul 2016 (20:07) → (4.4.0.28.30) to 4.4.0.31.33
  • 8 Aug 2016 (20:59) → (4.4.0.31.33) to 4.4.0.34.36
  • 31 Aug 2016 (10:40) → (4.4.0.34.36) to 4.4.0.36.38
  • 19 Sep 2016 (13:13) → (4.4.0.36.38) to 4.4.0.38.40

Atualizações do Kernel no Debian testing “Stretch” desde 19 Jun. 2016, — apenas 3 meses, — no Histórico do Synaptic:

  • 19 Jun 2016 (17:11) → linux-image-amd64 (4.5+73) to 4.6+74
  • 19 Jun 2016 (17:11) → linux-image-4.6.0-1-amd64 (4.6.1-1)
  • 28 Jun 2016 (12:41) → linux-image-4.6.0-1-amd64 (4.6.1-1) to 4.6.2-2
  • 12 Jul 2016 (08:39) → linux-image-4.6.0-1-amd64 (4.6.2-2) to 4.6.3-1
  • 24 Jul 2016 (12:41) → linux-image-4.6.0-1-amd64 (4.6.3-1) to 4.6.4-1

Desestimular “atualizações” de Kernel, portanto, é uma “política” específica do Linux Mint, — até então, “discreta”, — que agora se começa a trazer à tona.

Comparações



A decisão tomada, então, foi de ir com calma, alterando o mínimo possível as características do Linux Mint, — talvez mesmo remover o novo Kernel, como acabou sendo feito, depois.

E aproveitar para observar o comportamento das diferentes distribuições instaladas, — com suas respectivas “políticas”, — em vez de descaracterizá-las, logo de início:

  • Kubuntu, — com “atualizações” frequentes de Kernel, — e KDE “conservador”.
  • KDE Neon, — mesmo ritmo de Kernel, — e KDE “rolling release” [atualizou para 5.7.5 em 15 Set.].
  • Linux Mint 18 “Sarah” KDE, — Kernel “estabilizado”, — e KDE meio à frente.
  • Debian testing “Stretch”, — Kernel disparado na frente (por enquanto), — e KDE meio à frente [atualizou para o 5.7.4 em em 21 Set.].

A ideia é manter esse conjunto de características — diferenciadas — para melhor compreensão dessas 4 “distribuições” Linux, ao longo dos próximos 2 anos.

Vale notar, no entanto, que tudo isso é muito relativo.

O Kernel 3.19.0-32 do Linux Mint 17.3 (ISO de 5 Jan. 2016), estava bem “à frente” do Kubuntu 14.04 LTS, — que em 2 anos passou do Kernel 3.13.0-24 ao 3.13.0-85 (9 Abr. 2016), — lembrando tratar-se de “numeração” da Canonical (e não da Kernel.org).

  • Kubuntu 14.04 → linux-generic^3.13.0.24.28 / linux-headers-3.13.0-24^3.13.0-24.46
  • • 2014-05-31: Release: Linux Mint 17 → 3.13.0-24
  • Kubuntu 14.10 → linux-generic^3.16.0.23.24 / linux-headers-3.16.0-23^3.16.0-23.31
  • • 2014-11-29: Release: Linux Mint 17.1 → 3.13.0-37
  • Kubuntu 15.04 → linux-generic^3.19.0.15.14 / linux-headers-3.19.0-15^3.19.0-15.15
  • • 2015-06-30: Release: Linux Mint 17.2 → 3.16.0-38
  • Kubuntu 15.10 → linux-generic^4.2.0.16.18 / linux-headers-4.2.0-16^4.2.0-16.19
  • • 2015-12-04: Release: Linux Mint 17.3 → 3.19.0-32
  • Kubuntu 16.04 → linux-generic^4.4.0.21.22 / linux-headers-4.4.0-21^4.4.0-21.37

Portanto, o Mint 17.3 adotou o Kernel do Ubuntu 15.04, — embora “ancorado” no Ubuntu LTS (14.04).

Ou seja, a manutenção de um Kernel fixo por longos meses, no Linux Mint, não significa, necessariamente, ficar “para trás” em relação ao Ubuntu LTS, — pelo contrário, dá alguns saltos à frente dele, desde que o usuário faça a migração periódica para as evoluções de “ponto” (18.1, 18.2 etc.).

Além disso, é saudável questionar se Kernel “antigo”, por si só, é algo “negativo”, — ou se Kernel “novíssimo” constitui necessidade desabalada, — afinal, é muito comum usuários optarem por manter o Ubuntu LTS, durante 2 anos, com absoluto desprezo das versões “intermediárias” semestrais.

Nos fóruns e tutoriais, tendem a se superdimensionar questões relativas a hardwares “diferenciados”, — que não afetam a maioria dos usuários, — da mesma forma como publicações comerciais tendem a privilegiar os mais recentes (e caros) lançamentos, cujos anúncios são fonte de lucros.

São mecanismos da “indústria de consumo”, — e revistas e blogs também precisam de um fluxo de notícias e assuntos, para serem mais “consumíveis”, — mas não, uma necessidade imperiosa, para a maioria dos usuários, no mundo GNU/Linux.

Quanto ao Debian testing “Stretch”, registra-se apenas para controle. — De fato, não é comparável aos outros três: — Trata-se, na verdade, da futura “base” (em construção) a ser adotada no próximo Ubuntu LTS, — embora, depois, o Ubuntu se adiante em relação à versão “Stable” do Debian (que, uma vez lançada, “estaciona”).

Enfim, é de se observar que o Ubuntu tende a divergir cada vez mais da estrutura geral do Debian, e parece improvável que o Linux Mint ou o KDE Neon deixem de segui-lo, já que não se propõem alterar muito sua estrutura. — Essa “política” do Mint quanto ao Kernel é uma exceção, bastante “delimitada”, aliás, — seria necessário grande investimento (tempo, trabalho, colaboradores), para “divergir” do Ubuntu em maior amplitude.

As atualizações de Kernel no Ubuntu (e seus “derivados”) diferem do processo usado no Debian, — onde ocorre, de fato, uma “atualização” (não “acréscimo”), — e a “personalização” introduzida pelo Linux Mint em relação ao Ubuntu representa uma alteração bem mais modesta, em comparação.

De qualquer modo, essas observações servem, — do ponto de vista de um “leigo”, — para “distinguir” com mais nitidez (na prática) o “Kernel” (além do “ambiente gráfico”), — dentro de cada conjunto chamado “distribuição Linux”, — mas estão a anos-luz de representar qualquer “conhecimento” sobre o assunto.

De volta ao Kernel inicial


Demorando a leitura do material agora fornecido pelo Linux Mint sobre o assunto, — e que também exige alguma leitura sobre “Kernel”, — a decisão imediata foi restabelecer o sistema tal como veio, até encontrar tempo para pesquisar com calma.

Carregando o Linux Mint com o Kernel anterior, — ou não se poderá eliminar o mais recente

Na Sexta (26), foi decidido desinstalar o Kernel 4.4.0-34 (mais recente), — instalado no Sábado anterior (20).

Para fazer isso, o computador precisa ser reiniciado e, — no Menu de inicialização (Grub), — selecionar “Opções avançadas” → “Linux Mint 18 KDE 64-bit, with Linux 4.4.0-21-generic” — o Kernel original da instalação.

A regra básica é: — Para eliminar um Kernel, ele não pode estar em uso na sessão atual. — Primeiro, você precisa reiniciar o Linux, e carregá-lo com outro Kernel.

Uma vez “dentro” do Kernel original, o Kernel mais recente pode ser desinstalado sem problema, utilizando para isso o “Gerenciador de atualizações” (mintUpdate), — uma vez que o Synaptic do Linux Mint está inabilitado para essa tarefa.

Caminho para lidar com Kernel, no mintUpdate: — na seção “Ver”

O caminho para remover Kernel não parece “óbvio”, nem muito “intuitivo”, — fica um tanto “escondido” do usuário “comum”, — mesmo em um Menu com tão poucas opções.

Está em “Ver”:

mintUpdate → Ver → Kernels Linux

Avisos tenebrosos cercam a seção de Kernel, no mintUpdate

Escolhida a opção “Kernels”, o mintUpdate apresenta um Aviso assustador, — coisa de arrepiar os cabelos do pobre usuário “comum“, — em comparação com o Kubuntu, — que recomenda instalar e desinstalar Kernel, com a tranquilidade de quem veste uma roupa limpa e coloca a outra no cesto para lavar.

Vale a pena ler o “Aviso tenebroso”, — apesar da linguagem inadequada a um iniciante, por usar conceitos abstratos, que provavelmente ainda não lhe dizem nada, — mesmo após 5 ou 6 anos:

O kernel Linux é uma parte crítica do sistema. Regressões podem levar à falta de rede, falta de som, a falta de ambiente gráfico ou até mesmo a incapacidade de inicializar o computador. Apenas instalar ou remover kernels se você tem experiência com kernels, drivers, módulos DKMS e se você sabe como recuperar um computador que não carrega.
(…)
Se você estiver usando drivers proprietários, ou módulos DKMS, por favor, esteja ciente de que eles só vão trabalhar com os mais recentes kernel instalados no seu computador. Eles são recompilados cada vez que um novo kernel esteja instalado ou removido. Para usar drivers proprietários ou módulos DKMS com um kernel em particular, certifique-se de remover todos os kernels que são mais recente
.

Convém não clicar em “Do not show this message again”, — pelo menos, até o dia em que realmente entenda o suficiente, dessa algaravia, e se sinta seguro de que não precisará ler outra vez.

Porém, — mesmo sem fazer a menor ideia do que sejam “módulos DKMS”, — é possível entender que não basta “voltar a usar” um Kernel mais antigo, por default. — Será necessário remover qualquer Kernel mais recente, para que os bits & bytes voltem a ser recompilados com aquele Kernel anterior.

A “lógica funcional” sugere que “mais recente” refira-se à ordem cronológica de instalação, — já que foi esse processo que deflagrou a recompilação anterior, — mas a lógica pura (sem adjetivos) recomenda certificar-se disso com firmeza, e sem margem a equívocos, — sem esquecer uma breve análise combinatória das diferentes possibilidades de cronologia versus numeração, — tanto no histórico das instalações, quanto na sequência das remoções passadas e futuras, — etc.

Este é um exemplo de tarefa que não se sabe se o Synaptic “amputado” pelo Mint ainda seria capaz de conduzir a bom termo, — “automaticamente”.

Inútil dizer que, — em mais de 7 anos de “atualizações” quase mensais de Kernel no Kubuntu, — jamais foi registrado nenhum problema “perceptível”, — e tampouco houve necessidade de consertar nada, depois.

Hipótese: - Há uma desproporção enorme de pessoal e “recursos”, — entre a Canonical e a brava comunidade do Linux Mint, — além de tempo (“horas vagas”), — afinal, precisam sobreviver, já que não ganham para isso.

O “Kernel” não é algo que baste o Debian “pegar” no site Kernel.org, já “pronto para usar”, — nem algo que baste a Canonical “pegar” do Debian, — ou que baste a equipe heroica do Linux Mint “pegar” do Ubuntu.

Resta sempre um bom trabalho a realizar, — em cada “distro”, — e faz sentido racionalizar as prioridades.

Enfim, é sempre bom fazer uma pausa, — mudar o foco visual de 40 cm para 40 metros, digamos, — e pensar por quê, com mil terabytes, o Linux Mint se mantém invicto no ranking de interesse dos visitantes do Distrowatch, ano após ano, — e o Kurumin, com ainda menos recursos, permanece invicto na memória de seus antigos usuários, 10 anos após sua “descontinuação”.

Mas, sigamos adiante, — clique em “Continue”, para remover o Kernel que não se quer mais.

Kernel em uso na sessão atual não pode ser removido

Chama atenção, no quadro seguinte, a disponibilidade de nada menos que 4 Kernel não-instalados, — apenas 8 dias após 18 Ago. 2016, — data da ISO “Beta” instalada no dia 20.

Aí estão todas as “atualizações” de Kernel que o Kubuntu apresentou desde seu lançamento, — sem faltar uma só:

  • 6 May 2016 (18:50) → (4.4.0.21.22) to 4.4.0.22.23
  • 10 Jun 2016 (06:19) → (4.4.0.22.23) to 4.4.0.24.25
  • 27 Jun 2016 (17:04) → (4.4.0.24.25) to 4.4.0.28.30
  • 14 Jul 2016 (20:26) → (4.4.0.28.30) to 4.4.0.31.33
  • 8 Aug 2016 (18:58) → (4.4.0.31.33) to 4.4.0.34.36

Infelizmente, ao instalar a “atualização” mais recente, na semana anterior, — a única “notificada” pelo mintUpdate, no dia 20, — não chegou a ser aberta esta opção “Ver → Kernel Linux”, — por isso, não ficou documentado se todas essas versões já estavam disponíveis. — Provavelmente, sim.

O quadro traz algumas indicações fundamentais:

  • No alto, indica-se qual Kernel está em uso na sessão atual.

  • Apenas 2 Kernel estão instalados, — o primeiro e o último, — e por isso apresentam o botão “Remover”, quando se clica em um deles para exibir suas opções.

  • No caso do Kernel em uso, o botão “Remover” encontra-se desabilitado, — e ao passar o mouse sobre ele, surge o aviso de que “Este Kernel não pode ser removido”, pois está em uso no momento.

  • Ao clicar nos outros 4 Kernel, — para exibir suas opções, — apresenta-se o botão de “Instalar”.

Esse modo de apresentar o assunto tem algumas vantagens sobre o Synaptic “completo” do Kubuntu, — que apenas induz ao “fluxo” linear pré-estabelecido, de “instalar atualização” / “remover antigo”, — na medida em que facilita outras opções, como instalar / reinstalar qualquer Kernel anterior.

Um exemplo prático da “usabilidade” desse “modo Mint de ser” fica evidente no pedido de Clément Lefebvre adicionado ao 25º dos 274 comentários ao lançamento do Linux Mint 17.2, mais de um ano atrás:

Hi Luke, it could be kernel-related. Can you go in the Update Manager → View → Linux kernels and try other kernels? 3.13.0-37 was the one used in Mint 17.1, and 3.13.0-24 in Mint 17. You can also try newer 3.16 kernels, see if you can pinpoint this to be a kernel regression and what versions are affected. Check dmesg and /var/log/syslog for clues about these freezes as well. If your mouse freezes then it’s not related to Cinnamon and it probably will happen with MATE too.

Ainda que na época ainda não houvesse esta “política” atual de abordar o assunto com mais clareza — dentro do Linux Mint, — ele era corriqueiramente abordado no site / blog oficial / fórum etc.

Removendo o Kernel 4.4.0-34 (mais recente), instalado às 17:11 do Sábado (20)

Voltando ao nosso caso específico, apenas foi mandado desinstalar o Kernel mais recente, — que não estava em uso naquela sessão, — e mesmo assim, ainda foi dada mais uma chance para dúvidas cruéis:

“Tem certeza???” — Buuuuuu! — Que meda!

Mais 2 opções de Kernel, em menos de 30 dias, — acompanhando o ritmo do Kubuntu

22 Set. 2016 - Nas 4 semanas seguintes, esta seção “semi-oculta” do mintUpdate incorporou mais 2 versões de Kernel.

Infelizmente, o mintUpdate esteve configurado para não notificá-las, — nem exibi-las, ao ser aberto manualmente, — sabe-se lá desde quando.

O exame de uns 1.000 PrintScreen mostrou, apenas, que até às 22:07 de 26 Ago., o mintUpdate ainda estava configurado para notificar e exibir a disponibilidade de novo Kernel, — porém, às 17:48 de 21 Set., já se apresentava configurado para não avisar / exibir.

Nenhum registro de quando ocorreu essa alteração, — algum clique impensado, nessas 4 semanas que antecederam o exame disso tudo.

Viver é muito perigoso.

“New features”


Tela de boas-vindas ao carregar pela primeira vez o Linux Mint 18 instalado, com link para “Novos recursos”

Mesmo que não fosse exibida 1 única notificação de novo Kernel disponível, — logo após a instalação do Linux Mint 18 “Sarah” KDE, — o assunto já ganharia bastante visibilidade pelos 8 parágrafos + 3 prints dedicados ao “Update Manager” na página “Novos recursos” (“New features”), — linkada a partir do Anúncio de lançamento, — e também a partir das “Boas-vindas”, ao primeiro Boot.

Ilustração das “New features” sobre o mintUpdate. — Note o aviso sugerindo procurar um “mirror” mais rápido

“Novos recursos” começa por informar que 2 novas configurações permitem “ver e selecionar” atualizações de Kernel.

Embora não sejam propriamente “atualizações”, — mas disponibilidade de novos Kernel, — agora o “Gerenciador de atualizações” (mintUpdate) está habilitado a detectá-los e apresentá-los para instalação, como se fossem.

A afirmação de que isto se tornou possível “agora”, parece inexata, — se em Jun. 2015 Clem já sugeria “go in the Update Manager → View → Linux kernels and try other kernels”, — mas, parece a explicação mais provável de por quê isso não acontecia no Linux Mint 17.3.

O segundo ponto das “2 novas configurações” talvez seja o que se diz na frase seguinte: — Estas são “atualizações de Nível 5” (level 5 updates), mas agora é possível configurá-las em separado. — Ou seja: agora, você já pode optar por receber “notificação” do mintUpdate quando estiver disponível um novo Kernel.

“New features” afirma que a janela de gerenciamento de Kernel foi completamente redesenhada, e agora é precedida por um diálogo que “explica o que são Kernels, como selecioná-los no Boot e o que acontece aos módulos DKMS quando múltiplos Kernels são (ou estão) instalados”.

Refere-se àquele Aviso assustador, — exibido quando você clica em “Ver → Kernel Linux”, — até você clicar “Continue”, se tiver coragem.

Parece exagero afirmar que aquele Aviso assustador “explica o que acontece aos módulos DKMS” etc., — aliás, por mais que leia e releia… o que é “DKMS”?, — a menos que se refira àquela dica de que eles só são recompilados (automaticamente) para um Kernel anterior, quando você remove todos os Kernel mais recentes.

Links para os “Bug reports”, “Changelog” e “CVE Tracker” de cada Kernel

Anuncia, ainda, uma ótima novidade, — links para os “Bug reports”, “Changelog” e “CVE Tracker” de cada Kernel, — o que é muito mais racional do que tentar atualizar o mintUpdate, — todos os dias, — com toda essa massa de informações em rápida progressão.

A “Política de atualizações”


Tela de boas-vindas ao mintUpdate, com a escolha de uma “política de atualizações”

“New features” afirma que o “Gerenciador de atualizações” já era configurável, antes, mas não era muito claro como fazer isso, nem por quê. Os conceitos de “regressão”, de “estabilidade” e de “segurança” não eram explicados com clareza, — a crer que, agora, sejam.

Para aumentar a conscientização em torno destes conceitos e apresentar mais informações, existe agora uma nova tela de boas-vindas ao mintUpdate, — com 3 alternativas de “política de atualizações”, — “prontas para usar”:

1) Não quebre meu computador!
Recomendado para usuários iniciantes.
Apenas selecione as atualizações que são conhecidos para ser seguro ou que não impactam em partes críticas do sistema operacional.
Não me mostre atualizações que podem prejudicar a estabilidade do meu sistema.

2) Otimizar a estabilidade e a segurança
Recomendado para a maioria dos usuários.
Apenas selecione as atualizações que são conhecidos para ser seguro ou que não impactam em partes críticas do sistema operacional
Mas também me mostrar atualizações de segurança e kernel.

3) Sempre atualizar tudo
Recomendado para usuários experientes.
Selecione todas as atualizações disponíveis.
Manter o computador totalmente atualizado. Se uma regressão quebra alguma coisa, eu vou consertá-lo.

A alternativa padrão é a (2) segunda, — mostrar atualizações de segurança e de Kernel, — mas não marcá-las automaticamente para instalação.

A (1) primeira nem mostra tais coisas, — enquanto a (3) terceira marca tudo para instalar.

Adiante, veremos que também podem ser feitas opções mais detalhadas, — “personalizar” a política de atualizações.

Embora essa tela seja exibida automaticamente apenas ao carregar o mintUpdate pela primeira vez, ela pode ser acessada a qualquer momento em “Editar → Política de atualizações”.

Ajuda do mintUpdate para escolha de uma política de atualizações

Essa tela oferece, ainda, um botão de “Help”, com informações mais detalhadas, — embora pouco acrescente ao que já foi visto, — ou acrescente com pouca clareza:

Novas atualizações de patches, brechas de segurança conhecidas, corrigir erros conhecidos, mas eles também podem introduzir novas questões chamadas "regressões". (Provavelmente você quis dizer → «Novas atualizações fecham brechas na segurança e corrigem bugs, mas também podem introduzir novas falhas, chamadas “regressões”» by Google da Depressão).

Regressões são muito comuns, mas elas geralmente são rapidamente corrigidas por novas versões e eles raramente quebram partes críticas do sistema operacional.

Existem diferentes tipos de atualizações:

"Atualizações de software" são atualizações que corrigem erros (ou às vezes também que trazem novos recursos).

"Atualizações de segurança" são atualizações que trazem patches contra vulnerabilidades.

'Atualizações do kernel' representam a instalação de um novo kernel.

No Linux Mint, atualizações do kernel pode trazer ambos os patches de segurança e correções de bugs (e às vezes até mesmo novos recursos), e eles impactam em partes críticas do sistema operacional. Isso faz com que atualizações de kernel importantes do ponto de vista da segurança, mas também propensas a regressões que pode ser difícil de corrigir para usuários iniciantes.

As atualizações que você toma, o mais provável é que algo vai quebrar. Pode ser algo pequeno, algo que você não usa e que pode ser consertado com atualizações de amanhã. Mas, e se você não poder reiniciar? E se ele quebra seus drivers e você não pode mais fazer login ou se conectar à Internet?

Na mão, se você não atualizar qualquer coisa, você está perdendo correções de bugs, melhorias e mais importante patches para falhas de segurança.

Ao escolher uma política de atualização, pergunte a si mesmo as seguintes questões:

Você precisa de um software ou do kernel atualização em particular? Você está esperando para uma determinada correção de bug ou por algum dispositivo de hardware para ser reconhecido por um novo kernel?

Se as coisas forem mal, você é experiente o suficiente para corrigir o problema no seu computador? Sabe como corrigir problemas de inicialização, login, kernel e módulos?

Seu computador pode ser acessado por pessoas mal-intencionadas? Existem outros utilizadores locais neste computador ou na rede? Você executar um servidor ou qualquer outra coisa que as pessoas possam se conectar a partir do mundo exterior?

Tente avaliar o seu nível de experiência com Linux e suas necessidades quando se trata de correções de bugs e segurança.

Quando você escolhe uma política de atualização, algumas das preferências são alteradas no Gerenciador de Atualizações. Você pode ajustar essas preferências individualmente clicando no Edit → Preferências na barra de menu.

Fica-se sabendo, afinal, o modus operandi das assim chamadas “Regressões”:

“Regressões são muito comuns, mas elas geralmente são rapidamente corrigidas por novas versões e eles raramente quebram partes críticas do sistema operacional”.

Então, ficamos assim: — O bicho-papão raramente quebra alguma coisa séria, — e logo vai embora.

No fundo, não é má pessoa.

Preferências


mintUpdate → Editar → Preferências → Opções

Merece especial atenção o último parágrafo da “Ajuda”, — pois as 3 alternativas de “política de atualização” podem ser personalizadas em “Editar → Preferências”.

No quadro acima, — com 3 opções marcadas, — resume-se aquela (2) segunda “política de atualizações”, — que também poderia ser apelidada “o caminho do meio”, — nem tanto ao mar, nem tanto à terra.

Caso você desmarque “Sempre mostrar atualizações do Kernel + atualizações de segurança”, provavelmente recairá na (1) primeira alternativa de “política de atualizações”, — “Nem me mostre, que dá dor de cabeça”.

Mas se marcar as opções “Sempre selecionar atualizações do Kernel de confiança + atualizações de segurança”, provavelmente pulará para a (3) terceira alternativa de “política de atualizações”, — “Segura, peão!”

A adjetivação “Kernel de confiança” traz uma leve sugestão de que possa aparecer algum Kernel “não-confiável”, — mas, disso, ainda não foram avistadas provas cabais.

Mirrors & funcionalidades


Embora proponha mudar para um “mirror local”, na verdade o mintUpdate testa as velocidades para sua escolha

Outras opções, — como “ocultar o mintUpdate”, ou “só mostrar o ícone quando necessário” etc., — dizem respeito mais às aparências e funcionalidades, do que à “política de atualizações”.

A opção de “Não sugerir mudar para um mirror local” pode ser útil, caso rejeite a sugestão apresentada ao abrir o mintUpdate pela primeira vez, — e não queira que ele volte a insistir.

Na verdade, — caso aceite a sugestão, — ele fará um teste comparativo de velocidades, a partir de sua cidade, e você não é obrigado a escolher o mais “próximo” (geograficamente), — nem mesmo o mais rápido.

No fundo, tudo o que se deseja, é que o tráfego de dados na rede mundial seja racionalizado, — e que o planeta inteiro não fique pendurado em apenas 1 “mirror”, — aliás, o “default” de origem, que os demais “espelham”.

Escolhido o “espelho” da UFPR, o mintUpdate nunca mais voltou a falar nisso, — embora haja outros geograficamente mais próximos, e com velocidade igual ou talvez até maior.

Níveis


Escolhas avulsas para 5 “níveis” de atualizações, — ver e/ou marcar para instalação

Na aba “Níveis”, — à vista das explicações sobre como o Linux Mint classifica as atualizações em 5 categorias, — pode-se marcar / desmarcar, tanto a instalação automática quanto a mera exibição para escolha manual, — caso a caso.

Na aba “Atualização automática”, não há escolha alguma sobre atualização de pacotes de software, — mas, sim, sobre a frequência com que o mintUpdate deverá “recarregar” as informações dos repositórios de software. — No momento, está configurado para “reload” após 10 minutos do início da sessão, e novamente a cada 2 horas. — É provável que isto seja o “default”.

Quanto à “Lista negra”, encontra-se em branco, — com certeza, é o “default” de origem.

“Se não está quebrado, não conserte”


Para ser fiel à máxima de que “não se mexe em time que está ganhando”, a brava equipe do Linux Mint deveria seguir o lema “deixa quieto”. — Para que “levantar poeira”? — Mas, por esse caminho, ainda estaríamos na idade da pedra lascada.

Fato é que essa abordagem explícita de uma “política de Kernel”, antes silenciosa, — agora, em desafio aberto ao stress “obrigatório” universal, — pode valorizar o que muita gente já apreciava, e não sabia muito bem por quê.

“If it's not broke, don't fix it!”

Em um primeiro momento, vários usuários do Linux Mint ficaram um pouco perdidos, com o acréscimo de liberdade de escolha, — mas esclarecimentos simples fluem com facilidade, de outros usuários, — e tudo indica que, “entre mortos e feridos, salvaram-se todos”.


Aqui, a decisão já está consolidada: — A menos que haja um bom motivo, o Kernel original será mantido até a chegada do Linux Mint 18.1, do 18.2 etc., — ou também neles, se não for necessário “reinstalar do zero”, e a migração não recomendar ou exigir novo Kernel.

Descrição padrão de qualquer novo Kernel


Descrição padronizada do mintUpdate para novo Kernel

Uma única “descrição”, — ainda em inglês, — foi usada pelo mintUpdate para as 2 versões de Kernel já oferecidas:

“The Linux Kernel is responsible for hardware and drivers support. Note that this update will not remove your existing kernel. You will still be able to boot with the current kernel by choosing the advanced options in your boot menu. Please be cautious though.. kernel regressions can affect your ability to connect to the Internet or to log in graphically. DKMS modules are compiled for the most recent kernels installed on your computer. If you are using proprietary drivers and you want to use an older kernel, you will need to remove the new one first” (Copiado de: Here).

O Google Translate ofereceu tradução bastante inteligível, — em comparação com as demais apresentadas até aqui, — e com mais alguns retoques poderia ficar melhor ainda:

“O Linux Kernel é responsável pelo suporte de hardware e controladores. Note que esta “atualização” não irá remover seu kernel atual. Você ainda será capaz de arrancar com o Kernel atual, escolhendo as opções avançadas no seu menu de inicialização. Tenha cuidado, no entanto.. “regressões” do Kernel podem afetar sua capacidade de se conectar à Internet ou [fazer login graficamente]. Módulos DKMS são compilados para o Kernel mais recente instalado no seu computador. Se você estiver usando drivers proprietários e quiser usar um Kernel antigo, precisará remover o(s) mais novo(s), primeiro”.

A golpe do falso pedinte que solta um pombo com GPS dentro do seu carro


A página Ubuntu security notices dá uma boa ideia das falhas descobertas e corrigidas desde o lançamento do Ubuntu 16.04 LTS, — cerca de 100 registros em 150 dias (21 Abr. ~ 23 Set.), dos quais 21 referentes ao Kernel, e que podem ser agrupados em 7 unidades, — em geral, correspondendo às versões de Kernel disponibilizadas nos repositórios, e logo instaladas no Kubuntu / KDE Neon, ao longo desse período.

De um modo geral, essas brechas poderiam interessar muito mais para atacar Servidores de uma grande empresa ou órgão governamental, do que o Desktop doméstico do Zé das Couves, — ou dependem de acesso físico ao seu computador, ou de acesso a ele em rede local etc., — e o fato de que daqui a 3 ou 5 anos ainda estarão sendo descobertas brechas no Kernel do Xenial mostra a relatividade de interromper o trabalho, a qualquer hora do dia ou da noite, para instalar essas 7 correções sem perda de 1 segundo.

2016-09-19 - USN-3084-1: Linux kernel vulnerabilities
• 19 Sep 2016 (13:36) → (4.4.0.36.38) to 4.4.0.38.40

2016-08-29 - USN-3070-1: Linux kernel vulnerabilities
• 31 Aug 2016 (07:30) → (4.4.0.34.36) to 4.4.0.36.38

2016-08-10 - USN-3055-1: Linux kernel vulnerabilities
• 8 Aug 2016 (18:58) → (4.4.0.31.33) to 4.4.0.34.36

• 14 Jul 2016 (20:26) → (4.4.0.28.30) to 4.4.0.31.33

2016-06-27 - USN-3016-1: Linux kernel vulnerabilities
• 27 Jun 2016 (17:04) → (4.4.0.24.25) to 4.4.0.28.30

2016-06-10 - USN-3006-1: Linux kernel vulnerabilities
• 10 Jun 2016 (06:19) → (4.4.0.22.23) to 4.4.0.24.25

2016-05-16 - USN-2979-1: Linux kernel vulnerabilities

2016-05-06 - USN-2965-1: Linux kernel vulnerabilities
• 6 May 2016 (18:50) → (4.4.0.21.22) to 4.4.0.22.23

Traduções


Linhas 1 a 4

# Brazilian Portuguese translation for linuxmint
# Copyright (c) 2009 Rosetta Contributors and Canonical Ltd 2009
# This file is distributed under the same license as the linuxmint package.
# FIRST AUTHOR <EMAIL@ADDRESS>, 2009.

Linhas 31 a 164 — escolha de uma “política de atualizações”:

#: usr/share/help/C/mintupdate/policy.page:16(title)
msgid "Choosing an update policy"
msgstr "Escolhendo uma política de atualização"

#: usr/share/help/C/mintupdate/policy.page:18(p)
msgid ""
"New updates patch known security holes and fix known bugs, but they can also "
"introduce new issues called 'regressions'."
msgstr ""
"Novas atualizações de patches, brechas de segurança conhecidas, corrigir "
"erros conhecidos, mas eles também podem introduzir novas questões chamadas "
"\"regressões\"."

#: usr/share/help/C/mintupdate/policy.page:20(p)
msgid ""
"Regressions are very common but they are usually quickly fixed by new "
"updates and they rarely break critical parts of the operating system."
msgstr ""
"Regressões são muito comuns, mas elas geralmente são rapidamente corrigidas "
"por novas versões e eles raramente quebram partes críticas do sistema "
"operacional."

#: usr/share/help/C/mintupdate/policy.page:22(p)
msgid "There are different types of updates:"
msgstr "Existem diferentes tipos de atualizações:"

#: usr/share/help/C/mintupdate/policy.page:25(p)
msgid ""
"'Software updates' are updates which fix bugs (or also sometimes which bring "
"new features)."
msgstr ""
"\"Atualizações de software\" são atualizações que corrigem erros (ou às "
"vezes também que trazem novos recursos)."

#: usr/share/help/C/mintupdate/policy.page:26(p)
msgid "'Security updates' are updates which patch vulnerabilities."
msgstr ""
"\"Atualizações de segurança\" são atualizações que trazem patches contra "
"vulnerabilidades."

#: usr/share/help/C/mintupdate/policy.page:27(p)
msgid "'Kernel updates' represent the installation of a newer kernel."
msgstr "'Atualizações do kernel' representam a instalação de um novo kernel."

#: usr/share/help/C/mintupdate/policy.page:30(p)
msgid ""
"In Linux Mint, kernel updates bring both security patches and bug fixes (and "
"sometimes even new features), and they impact critical parts of the "
"operating system. This makes kernel updates important from a security point "
"of view, but also prone to regressions which can be hard to fix for novice "
"users."
msgstr ""
"No Linux Mint, atualizações do kernel pode trazer ambos os patches de "
"segurança e correções de bugs (e às vezes até mesmo novos recursos), e eles "
"impactam em partes críticas do sistema operacional. Isso faz com que "
"atualizações de kernel importantes do ponto de vista da segurança, mas "
"também propensas a regressões que pode ser difícil de corrigir para usuários "
"iniciantes."

#: usr/share/help/C/mintupdate/policy.page:32(p)
msgid ""
"The more updates you take, the more likely something will break. It might be "
"something small, something you don't use and it might get fixed with "
"tomorrow's updates. But what if you can't reboot? what if it breaks your "
"drivers and you can no longer log in or connect to the Internet?"
msgstr ""
"As atualizações que você toma, o mais provável é que algo vai quebrar. Pode "
"ser algo pequeno, algo que você não usa e que pode ser consertado com "
"atualizações de amanhã. Mas, e se você não poder reiniciar? E se ele quebra "
"seus drivers e você não pode mais fazer login ou se conectar à Internet?"

#: usr/share/help/C/mintupdate/policy.page:34(p)
msgid ""
"On the other hand, if you don't update anything, you're missing bug fixes, "
"improvements and more importantly patches for security holes."
msgstr ""
"Por outro lado, se você não atualizar nada, você deixará de consertar erros, "
"de receber melhorias e perderá correções importantes contra falhas de "
"segurança."

#: usr/share/help/C/mintupdate/policy.page:36(p)
msgid "When choosing an update policy, ask yourself the following questions:"
msgstr ""
"Ao escolher uma política de atualização, pergunte a si mesmo as seguintes "
"questões:"

#: usr/share/help/C/mintupdate/policy.page:39(p)
msgid ""
"Do you need a particular software or kernel update? Are you waiting for a "
"particular bug fix or for some hardware device to be recognized by a newer "
"kernel?"
msgstr ""
"Você precisa de um software ou do kernel atualização em particular? Você "
"está esperando para uma determinada correção de bug ou por algum dispositivo "
"de hardware para ser reconhecido por um novo kernel?"

#: usr/share/help/C/mintupdate/policy.page:40(p)
msgid ""
"If things go wrong, are you experienced enough to fix your computer? Do you "
"know how to fix boot, login, kernel and module issues?"
msgstr ""
"Se as coisas forem mal, você é experiente o suficiente para corrigir o "
"problema no seu computador? Sabe como corrigir problemas de inicialização, "
"login, kernel e módulos?"

#: usr/share/help/C/mintupdate/policy.page:41(p)
msgid ""
"Can your computer be accessed by malicious people? Are there other local "
"users on this computer or on the network? Do you run a server or anything "
"people can connect to from the outside world?"
msgstr ""
"Seu computador pode ser acessado por pessoas mal-intencionadas? Existem "
"outros utilizadores locais neste computador ou na rede? Você executar um "
"servidor ou qualquer outra coisa que as pessoas possam se conectar a partir "
"do mundo exterior?"

#: usr/share/help/C/mintupdate/policy.page:44(p)
msgid ""
"Try to assess your level of experience with Linux, and your requirements "
"when it comes to bug fixes and security."
msgstr ""
"Tente avaliar o seu nível de experiência com Linux e suas necessidades "
"quando se trata de correções de bugs e segurança."

#: usr/share/help/C/mintupdate/policy.page:46(p)
msgid ""
"When you choose an update policy, some of the preferences are changed in the "
"Update Manager. You can tune these preferences individually by clicking on "
"the Edit-&gt;Preferences menu in the menubar."
msgstr ""
"Quando você escolhe uma política de atualização, algumas das preferências "
"são alteradas no Gerenciador de Atualizações. Você pode ajustar essas "
"preferências individualmente clicando no Edit-&gt;Preferências na barra de "
"menu."

Linhas 272 a 331 — sobre Kernel:

#: usr/lib/linuxmint/mintUpdate/kernelwindow.py:231
msgid ""
"The Linux kernel is a critical part of the system. Regressions can lead to "
"lack of networking, lack of sound, lack of graphical environment or even the "
"inability to boot the computer. Only install or remove kernels if you are "
"experienced with kernels, drivers, DKMS modules and you know how to recover "
"a non-booting computer."
msgstr ""
"O kernel Linux é uma parte crítica do sistema. Regressões podem levar à "
"falta de rede, falta de som, a falta de ambiente gráfico ou até mesmo a "
"incapacidade de inicializar o computador. Apenas instalar ou remover kernels "
"se você tem experiência com kernels, drivers, módulos DKMS e se você sabe "
"como recuperar um computador que não carrega."

#: usr/lib/linuxmint/mintUpdate/kernelwindow.py:232
msgid ""
"You can install multiple kernels on your computer and you can select the one "
"you want to use from the advanced options in the boot menu."
msgstr ""
"Você pode instalar vários kernels em seu computador, e você pode selecionar "
"o que você deseja usar nas opções avançadas no menu de inicialização."

#: usr/lib/linuxmint/mintUpdate/kernelwindow.py:233
msgid ""
"By default, your computer will boot with the most recent kernel installed."
msgstr ""
"Por padrão, o computador irá dar boot com o mais recente kernel instalado."

#: usr/lib/linuxmint/mintUpdate/kernelwindow.py:234
msgid ""
"If you are using proprietary drivers, or DKMS modules, please be aware that "
"they will only work with the most recent kernel installed on your computer. "
"They get recompiled every time a new kernel is installed or removed. To use "
"proprietary drivers or DKMS modules with one particular kernel, make sure to "
"remove all the kernels which are more recent."
msgstr ""
"Se você estiver usando drivers proprietários, ou módulos DKMS, por favor, "
"esteja ciente de que eles só vão trabalhar com os mais recentes kernel "
"instalados no seu computador. Eles são recompilados cada vez que um novo "
"kernel esteja instalado ou removido. Para usar drivers proprietários ou "
"módulos DKMS com um kernel em particular, certifique-se de remover todos os "
"kernels que são mais recente."

Linhas 595 a 653 — as 3 opções de “política de atualização”:

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1340
#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1695
msgid "Please choose an update policy."
msgstr "Por favor, escolha uma política de atualização."

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1341
msgid "Don't break my computer!"
msgstr "Não quebre meu computador!"

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1342
msgid "Recommended for novice users."
msgstr "Recomendado para usuários iniciantes."

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1343
#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1346
msgid ""
"Only select updates which are known to be safe or which do not impact "
"critical parts of the operating system."
msgstr ""
"Apenas selecione as atualizações que são conhecidos para ser seguro ou que "
"não impactam em partes críticas do sistema operacional."

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1343
msgid "Don't show me updates which can harm the stability of my system."
msgstr ""
"Não me mostre atualizações que podem prejudicar a estabilidade do meu "
"sistema."

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1344
msgid "Optimize stability and security"
msgstr "Otimizar a estabilidade e a segurança"

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1345
msgid "Recommended for most users."
msgstr "Recomendado para a maioria dos usuários."

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1346
msgid "But also show me security and kernel updates."
msgstr "Mas também me mostrar atualizações de segurança e kernel."

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1347
msgid "Always update everything"
msgstr "Sempre atualizar tudo"

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1348
msgid "Recommended for experienced users."
msgstr "Recomendado para usuários experientes."

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1349
msgid "Select all available updates."
msgstr "Selecione todas as atualizações disponíveis."

#: usr/lib/linuxmint/mintUpdate/mintUpdate.py:1349
msgid ""
"Keep my computer fully up to date. If a regression breaks something, I'll "
"fix it."
msgstr ""
"Manter o computador totalmente atualizado. Se uma regressão quebra alguma "
"coisa, eu vou consertá-lo."

Fonte: mint-translations/po-export/mintupdate/mintupdate-pt_BR.po (em 19 Set. 2016).

Dúvida cruel:

Should I install/update the Linux Kernel?

________
Publicado inicialmente em 26 Ago. 2016, às 13:05, para desenvolvimento nos dias seguintes.

— … ≠ • ≠ … —

Linux Mint



Kubuntu & KDE


segunda-feira, 4 de julho de 2016

Linux Mint 17.3 KDE em Live USB

Linux Mint 17.3 KDE na 2ª sessão do atual teste de trabalho Live USB (Pendrive)

Este teste de trabalho em Live USB visava confirmar, — ou alterar, — a decisão de substituir o Cinnamon pelo KDE, ao migrar do Linux Mint 17.3 para o Linux Mint 18.

Na qualidade de leigo em “tecnologia”, tinha algum receio de que o Linux Mint, — cujo “ambiente” típico é o Cinnamon, como que “feitos um para o outro”, — não se adaptasse bem ao KDE, e vice-versa.

Dúvida superada.

Até onde foi possível avaliar, — apenas em Live USB, e com as limitações de mero usuário mortal, — a integração Mint / KDE não parece deixar nada a desejar.

Pelo contrário, — traz algumas boas surpresas, que não conhecia no antigo Kubuntu 14.04.

Enquanto o Mint 18 KDE não vem


Se a cronologia passada servir de parâmetro, falta um mês para o lançamento do Linux Mint 18 KDE.

  • Da liberação do Linux Mint 17.3 Cinnamon e MATE Beta (23 Nov. 2015) até a do Xfce e KDE Beta (26 Dez. 2015) passaram-se 33 dias.

  • Do lançamento do Linux Mint 17.3 Cinnamon e MATE (4 Dez. 2015) até o lançamento do Xfce e KDE (9 Jan. 2016) passaram-se 36 dias.

Extrapolando esses 33~36 dias a partir do recente lançamento do Linux Mint 18 Cinnamon (30 Jun. 2016), pode-se imaginar que o Linux Mint 18 KDE seja lançado nos primeiros dias de Agosto.

Porém, extrapolando 33~36 dias desde a versão Beta Cinnamon e Mate (9 Jun. 2016), pode-se ter esperança de que a Beta do Xfce e do KDE saia daqui a uma semana, ou pouco mais.

Decidido a substituir também o Cinnamon pelo KDE, — a partir do Linux Mint 18, — este prazo precisava ser usado para conhecer o KDE no Mint, de modo a confirmar (ou mudar) essa decisão.

Com isso, finalmente pude começar a distinguir o que é específico do Linux Mint, — do que é específico do Cinnamon.

Sessões Live USB


O teste de trabalho foi realizado em 3 sessões:

A 1ª sessão foi carregada no Sáb., 2 Jul. 2016, às 18:13, e se prolongou até 0:28 da Seg., 4 Jul. 2016, no total de 30h15min (pelo menos). — Deveria se prolongar, porém houve falta de energia durante a madrugada, e o computador amanheceu desligado. Foi necessário carregar nova sessão Live USB.

A 2ª sessão foi carregada na Seg., 4 Jul. 2016, às 9:45, e se prolongou até à 0:24 da Ter., 5 Jul. 2016, no total de 14h40min.

A 3ª sessão foi carregada na Qui., 7 Jul. 2016, às 14:02, e se prolongou até 1:32 da Sex., 8 Jul. 2016, no total de 11h30min.

Drive SSD, Nokia Lumia e Sony DSC-H2


Recorde de uso de Swap e CPU, ao abrir um diretório com milhares de subdiretórios no Dolphin

Foram conectados por cabo USB o celular e a câmera digital, para baixar fotos, — devidamente renomeadas pelo pyRenamer, — e excepcionalmente um SSD externo de 1 Terabyte.

Navegar pelo Dolphin entre os 230.000 arquivos do SSD externo, — sem lembrar de fechar o Chromium, Gimp, LibreOffice, — fez com que o uso de Memória Swap chegasse a 2,7 GiB.

Esse “recorde” foi atingido às 14:11, na Segunda-feira, ao tentar abrir um diretório com mais de 5 mil subdiretórios, — ignoro quantos no primeiro “nível”. — O sistema pareceu “travado”, mas foi só impressão. Depois de alguns minutos, as coisas voltaram a andar, ainda que um tanto lentas a princípio.

Nessa hora, a possibilidade de “ver” no KSysguard o que estava acontecendo, — uso de praticamente 100% da CPU, — foi muito útil para evitar o pânico. Mesmo no momento em que tudo parecia “travado”, a verdade é que muitas coisas estavam acontecendo. Inclusive, provavelmente, gravação de dados da Memória RAM no Swap.

O exame do SSD externo foi deixado para outra ocasião, — embora ainda conectado e aberto no Dolphin, — e a 2ª sessão Live USB prosseguiu normalmente, por mais 10 horas, com pequenas “instabilidades” no Chromium / Facebook, — e nenhum crash.

Às 15:19, o uso do Swap já havia caído para 2,0 GiB, — ainda com o SSD externo aberto no Dolphin; — às 16:08 caiu para 1,4 GiB, com o fechamento do LibreOffice; mas à 0:24 caiu apenas até 1,3 GiB, com o fechamento do Chromium.

Limpeza da listagem “Terabyte-Arquivos.txt”, no Mint Cinnamon (instalado)

Nos dias subsequentes, o SSD externo foi examinado a partir dos sistemas Linux instalados, — Mint 17.3 Cinnamon e Kubuntu 16.04, — usando comandos para documentar em TXT todos os arquivos existentes:

flavio@linux2:/media/flavio/Terabyte$ ls -l -R > Terabyte-Arquivos.txt

e a árvore completa, por meio desse comando verdadeiramente troglodita, encontrado pronto:

ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//--/g' -e 's/^/   /' -e 's/-/|/' > Terabyte-Arvore.txt

O Linux Mint 17.3 Cinnamon (instalado) não chegou a ser submetido a nenhum grande “esforço”, — exceto esses comandos, e a posterior eliminação (substituição) em massa de umas 350.000 ocorrências de strings, tipo “-rw------- 2 flavio flavio”, referentes às permissões, proprietário, grupo etc. dos arquivos, — inclusive no $RECYCLE.BIN, — listados em Terabyte-Arquivos.txt, que assim pôde ser reduzido de 23,5 MiB para 13,7 MiB, no gedit.

É sempre mais prático procurar nomes e siglas por CTRL-F em um arquivo TXT, — com direito às informações de tamanho e localização, — do que em um SSD inteiro.

Árvore de diretórios gerado para o arquivo “Terabyte-Arvore.txt” no Mint Cinnamon (instalado)

Nada disso exige tanto do sistema, como exigiria a exibição “gráfica” para navegar no Dolphin, — na base do “olhômetro”, muito ineficiente, — e mal chegou a elevar a temperatura da CPU a uns 58ºC, durante alguns minutos.

Cálculo do espaço e conteúdo de uma grande pasta pelo Dolphin

O esforço maior acabou ficando para o Kubuntu 16.04 (instalado), onde o Dolphin confirmou-se um tanto inadequado para lidar com grande número de diretórios e arquivos.

Deletando milhares de arquivos do diretório $RECYCLE.BIN, no Krusader

Por fim, foi usado o Krusader para deletar, — sem passar pela “lixeira”, — dois diretórios com um número descomunal de antigos softwares para MS-DOS e Windows; e mais de 6 mil arquivos “apagados”, que continuavam intactos no diretório $RECYCLE-BIN. Uma “limpeza” de cerca de 140 GiB em uns 20 minutos (18:56~19:17).

Tarefas que, feitas as contas, não eram mesmo para uma sessão Live USB, — embora pudesse ser feito, se instalasse o Krusader e adotasse de imediato todas essas “estratégias”.

Dados Exif instantâneos


“Preview” da foto do início da 1ª sessão Live USB do Linux Mint 17.3 KDE, com todos os dados Exif

Ao comentar em uma comunidade Mint a minha surpresa com vários recursos do Linux Mint 17.3 KDE, que nunca tinha visto no Kubuntu, no Debian KDE, nem no KDE Neon, — todos em versões mais recentes do que ele, — um amigo respondeu, com o entusiasmo que caracteriza os adeptos dessa “distribuição”: — «en cualquier versión de mint encontraras esos detalles y herramientas que no estan presentes en los escritorios originales eso es lo que diferencia a Linux Mint del resto».

É o caso, p.ex., do Dolphin 4.14.2, quando se passa o ponteiro do mouse sobre uma imagem original, — intocada por editor de imagens ou pelo “tratamento” automático recebido ao fazer upload em portais como Facebook, — e pula diante dos olhos um “preview” com todos os dados Exif da fotografia.

Parando todos os “processos” Akonadi pelo KSysguard

Detalhe importante: — Uma das primeiras providências, ao iniciar a sessão Live USB do Linux Mint 17.3 KDE, foi conferir que “Pesquisa de arquivos” (Desktop search) estava desabilitado, e encerrar (pelo KSysguard) todos os “processos” Akonadi, — recursos que já vi serem recomendados para 1.001 utilidades, inclusive lidar com dados Exif, mas que na prática até hoje ainda não mostraram serviço.

Como encontrar quem informe, em um órgão público, a data de uma foto específica?

Quando se tenta obter informações sobre alguns milhares de fotos originais, das mais diversas procedências, — e sabem os colaboradores o quanto pode ser chato um “editor” que vive fazendo perguntas, — esse tipo de recurso vale mais do que mil efeitos gráficos no “desktop”.

Isso, quando o colaborador é seu chapa, amigão. — Mas, e na “máquina governamental”, — federal, estadual ou municipal, p.ex.?

Não duvido que se possa obter esse recurso no Kubuntu, no Debian ou no KDE Neon, — talvez até com a maior facilidade do mundo, — mas o fato é que nunca encontrei qualquer dica sobre isso, após meses procurando, pesquisando, e instalando dúzias de plugins.

Nos dias 5 e 6, o Kubuntu, o Debian KDE e o KDE Neon voltaram a ser examinados, na vã esperança de que algo semelhante pudesse ser obtido, ali, no Dolphin.

Fotos copiadas (drag-and-drop) no Dolphin, com as datas e horas originais do celular

Também não é comum, ao baixar fotos da câmera digital ou do celular, por simples arrastar-e-soltar (cópia) pelo Dolphin, — não pelo DigiKam, Gwenview, gThumb etc., — os arquivos trazerem suas datas e horas originais.

No dia 1º Jul. 2016, p.ex., foram baixadas 828 fotos do celular pelo Nemo, no Mint Cinnamon, — e todos os 828 arquivos estão “datados” desse dia, às 13:44~13:45 (sim, o processo durou 1 minuto).

Download e gravação ISO → Pendrive


Gravação da ISO do Linux Mint KDE no Pendrive, por comando “cp”

Sáb., 2 Jul. 2016 - A imagem ISO “linuxmint-17.3-kde-64bit.iso” foi baixada por Torrent às 13:38~13:54; e gravada no Pendrive por comando “cp” às 18:03~18:08.

A sessão Live USB foi carregada por volta das 18:13 (Foto de celular).

A primeira providência foi configurar o Fuso horário (18:15), para dispor de Capturas de tela corretamente datados desde o início, já que o aplicativo KSnapshot só parece oferecer numeração sequencial dos prints, para automação dos nomes de arquivo, portanto sem registro “visível” da hora (Foto de celular).

18:17 – Fuso horário e KSnapshot.

Configuração básica do Dolphin (18:18~18:21).

18:19 – O Dolphin “agrupa” os arquivos, separando-os por números e letras 0-9, A, B, C etc. (Foto de celular).

A constatação foi feita logo após a montagem da partição “F”, — necessária para que o KSnapshot possa salvar as Capturas de tela no HD, — lembrando que, numa sessão “Live USB” a pasta “home” é volátil, meramente “virtual” (Memória RAM), e tudo que for gravado ali poderá desaparecer num piscar de olhos, caso ocorra um “pico” momentâneo da rede elétrica.

Instalados pelo Synaptic:

Sat Jul  2 18:47:35 2016

Upgraded:

libcurl3 (7.35.0-1ubuntu2.5) to 7.35.0-1ubuntu2.6

Installed:

chromium-browser (51.0.2704.79-0ubuntu0.14.04.1.1121)
chromium-browser-l10n (51.0.2704.79-0ubuntu0.14.04.1.1121)
chromium-codecs-ffmpeg-extra (51.0.2704.79-0ubuntu0.14.04.1.1121)
conky-all (1.9.0-4)
curl (7.35.0-1ubuntu2.6)
fancontrol (1:3.3.4-2ubuntu1)
hddtemp (0.3-beta15-52)
libaudclient2 (3.4.3-1)
libdee-1.0-4 (1.2.7+14.04.20140324-0ubuntu1)
libid3tag0 (0.15.1b-10ubuntu1)
libimlib2 (1.4.6-2)
liblua5.1-0 (5.1.5-5ubuntu0.1)
libunity-protocol-private0 (7.1.4+14.04.20140210-0ubuntu1)
libunity-scopes-json-def-desktop (7.1.4+14.04.20140210-0ubuntu1)
libunity9 (7.1.4+14.04.20140210-0ubuntu1)
libxmmsclient6 (0.8+dfsg-9)
psensor (0.8.0.3-1ubuntu3)
psensor-common (0.8.0.3-1ubuntu3)
pyrenamer (0.6.0-1.1)
python-gconf (2.28.1+dfsg-1ubuntu2)
python-hachoir-core (1.3.3-3)
python-hachoir-metadata (1.3.3-1)
python-hachoir-parser (1.3.4-1)
python-support (1.0.15)
ttf-mscorefonts-installer (3.4+nmu1ubuntu1)
update-notifier-common (0.154.1ubuntu1)

Obs.: Nenhum pacote instalado por comando “apt”:

mint@mint:~ > history
    1  sudo sensors-detect
    2  clear
    3  sudo watch sensors
    4  exit
    5  cat /proc/swaps
    6  lsblk -f
    7  history

18:41 – KSysguard indica Swap de 16,2 GiB.

Desativando o uso das partições de Swap pertencentes ao Debian testing “Stretch” (Linux3)

18:43 – Utilizado o KDE Partition Manager para desativar o uso de 2 das 8 partições Swap: “Swap3a” e “Swap3b”, pertencentes ao Debian testing “Stretch” (Foto de celular). O alerta veio da observação do KSysguard, indicando “16,2 GiB de Swap”. Ao que parece, nada havia sido gravado nessas partições, ainda. — P.S.: Infelizmente, na Seg., 4 Jul. 2016, ao ter de iniciar nova sessão (ver abaixo), esqueci esse detalhe. Ao longo do dia houve verdadeiro “abuso” do Live Mint KDE, com uso de mais de 2 GiB de Swap. Torcendo, agora, para que o Debian não apresente sequelas.

18:44 – KSysguard indica Swap de 12,2 GiB, porém de modo contraditório, — em outra parte, ele mesmo continua indicando 16,2 GiB (isso passou desapercebido até o dia seguinte).

Edição do arquivo “.conkyrc”, copiado do Debian

Copiado e editado o arquivo “.conkyrc” do Debian para colar na “home” do Live USB Linux Mint 17.3 KDE (18:53~18:57). — A padronização dos Rótulos (Label) das partições fez com que essa edição seja bastante simples e rápida.

19:15 – Aplicado Wallpaper.

19:17 – Um erro de edição do arquivo “.conkyrc” foi corrigido às 19:17.

19:20 – Conky, Psensor e KSysguard funcionando.

Ajuste das “propriedades da janela específica” do Psensor, no KWin: lembrar posição e tamanho

19:23 – Ajuste das “propriedades da janela específica” do Psensor, pelo KWin, para que, — ao reabrir (automaticamente, no início de cada sessão), — “lembre” a posição e o tamanho exato.

Isso é particularmente útil para lidar com o Psensor, rebelde até à sua própria configuração interna de “restaurar tamanho e posição”.

Menu de opções para o controle de janelas do KWin

Este conjunto de configurações do KWin, bastante amplo, é uma das inúmeras características do KDE que fazem muita falta no Cinnamon, p.ex., onde a janela do Psensor precisa ser ajustada manualmente, a cada início de sessão.

Intervalos do Psensor precisam ser ajustados de 2 para 1 segundo

19:30 – Comando “sudo watch sensors” para conferir (após o “sudo sensors-detect”). Terminal (Konsole) já parcialmente configurado. — Conky ok.

Há 2 pontos em que o intervalo do Psensor precisa ser ajustado, de 2 para 1 segundo, em Preferências → Grafo, e em Preferência → Sensores.

KSysguard segue dando informações contraditórias sobre o Swap disponível. — Só corrigiu após ser fechado e reaberto.

Menu em “cascata”: muito mais prático do que o Menu K original

19:43 – Menu K substituído pelo Menu “cascade”. — Embora no Mint 17.3 KDE não haja uma identificação, tudo indica tratar-se do “Homerun Kicker”.

20:03 – Conexão por cabo USB da câmera Sony DSC-H2 para baixar um vídeo e algumas fotos recentes (até 20:08).

20:08 – Aplicada configuração de “clique único” (single-click) no Dolphin, com reflexo nos demais diálogos KDE.

Desconectar com segurança o cabo USB da câmera digital Sony DSC

20:10 – Desconectar com segurança a câmera Sony DSC-H2.

20:14 – Vídeo no Dragon Player.

21:03 – Configuração do layout de Teclado (PT-BR) e acesso ao 3º nível.

Opções da conexão USB Nokia Lumia (WP8)

21:44 – Conexão por cabo USB do celular Nokia Lumia (WP8). Das 4 opções de “ação”, existem 2 opções “Open with file manager”. A primeira delas dá erro; a segunda funciona com perfeição.

21:48 – Baixadas as 19 fotos mais recentes.

21:49 – Não existe opção de “desmontar”, “ejetar” ou “desconectar com segurança” o Nokia Lumia, no menu de contexto do Dolphin. Restou puxar o cabo assim mesmo. Nenhum dano observado até o dia seguinte pela manhã.

Renomeando 856 fotos de celular com pyRenamer: intensa atividade de CPU

22:01 – Aberto pyRenamer para renomear 856 fotos para o padrão “YYYY-MM-DD_HH-MM-SS_NL.jpg”. — O mais demorado é o processamento ao clicar em “Preview” (22:04~22:06), com intensa atividade de CPU.

22:07 – Ao clicar em “Rename”, os 856 arquivos são renomeados num piscar de olhos.

Obs.: Ao passar o apontador do mouse sobre um arquivo ainda no celular, o Dolphin exibe uma prévia da foto, e nada mais. — Porém, depois de copiados os arquivos para o HD, ao passar o ponteiro do mouse sobre um arquivo, a prévia da imagem vem acompanhada dos dados Exif da foto.

23:00 – KSysguard ainda contraditório, com 2 valores diferentes de Swap.

Domingo, 3 Jul. 2016


8:40 – Percebido que KSysguard aponta 16,2 GiB de Swap, no local mais visível (e 12,2 GiB em local mais discreto). KDE Partition Manager confirma que as partições Swap3a e Swap3b. — do Debian, — não estão sendo usadas.

8:50 – Comandos “cat /proc/swaps” e “lsblk -f” confirmam que as partições Swap do Debian não estão sendo usadas.

8:56 – KSysguard é fechado e novamente aberto, — e finalmente passa a exibir o valor correto do Swap, nas 2 indicações.

9:19 – Aberto o Gimp (configuração original: janelas de ferramentas incorporadas na janela principal).

9:22 – Opções de salvar configurações personalizadas de ferramentas do Gimp.

9:23 – Personalizadas e salvadas as opções de ferramentas do Gimp.

9:53 – Mais um ajuste no Conky, para exibir “K/ home1” e “M/ home2”.

9:54 – Salvar “.conkyrc” não basta para fazer efeito. É necessário encerrar o Conky e chamar novamente.

9:56 – Encerrados vários “processos” Akonadi, pelo KSysguard. Nenhum efeito perceptível no uso da Memória RAM. Não encontrado qualquer processo claramente associado ao PIM — Personal Information Manager do KDE.

12:10 – Desabilitado KDEwallet. Confirmado que Akonadi não está rodando.

Seg., 4 Jul. 2016


Estado do sistema após 30 horas, fechando tudo exceto Conky, Psensor, KSysguard e Dolphin

O computador ficou ligado, mas pela manhã estava parado, embora com a energia ligada (LEDs da Mobo e do Monitor). Mais tarde, foi confirmado que faltou energia em algum momento da madrugada.

Prints desse dia começam no nº 100 (o último da véspera foi nº 89).

Refazendo os passos da véspera, na Segunda-feira

Anotações, com a cópia dos pacotes instalados na véspera pelo Synaptic, foram uma mão-na-roda para refazer essa parte rapidamente.

Prudência e canja de galinha


O KDE, — “ambiente gráfico” que prefiro cada vez mais, — era o único que ainda não conhecia no Linux Mint.

Já instalei o Linux Mint Xfce, em 2011; e o Linux Mint Cinnamon, em 2014 e 2016. Também já testei o Linux Mint MATE, há vários anos, ainda em “Live CD”; e este ano o Linux Mint Debian Edition (LMDE-2) MATE, em Live USB. Apenas o Linux Mint KDE, nunca havia testado nem instalado.

Talvez porque quisesse aproveitar cada iniciativa para conhecer 2 coelhos de uma tacada só, — Mint + Cinnamon, Mint + Xfce, Mint + MATE, — pois o KDE já conhecia no Kurumin, no Kubuntu e no Debian, as “distros” com as quais sempre consegui trabalhar melhor.

A recente instalação do Debian testing “Stretch” com todos os “ambientes gráficos”, — Xfce, Gnome, KDE, Cinnamon, MATE, LXDE, — me “curou” dessa curiosidade.

Em poucas horas, pude percorrer todos esses “ambientes gráficos”, dentro de uma mesma “distro”, — mais: dentro de uma mesma instalação, — e em poucos dias pude examiná-los e compará-los de modo sistemático, quanto ao que cada um permite ou não permite (excluídas as configurações só possíveis por comandos “trogloditas”).

E a conclusão é que, — embora cada um desses “ambientes gráficos” ofereça muitas qualidades e características, que ainda estou longe de conhecer, — é com o KDE que vou continuar trabalhando.

___________
Relato produzido e publicado durante o teste de trabalho em Live USB com Linux Mint 17.3 KDE, — cuja 1ª sessão começou no Sáb., 2 Jul. 2016; retomado em 2ª sessão na Seg., 4 Jul. 2016; e novamente retomado em 3ª sessão na Qui., 7 Jul. 2016.

— … ≠ • ≠ … —

Linux Mint



Kubuntu & KDE