Translate

terça-feira, 30 de agosto de 2016

Corrigindo pontos de montagem no Linux Mint 18 KDE

A “página inicial” do Dolphin não podia ser aberta, pelo caminho “/media/flavio/F”

A instalação do Linux Mint 18 “Sarah” KDE (Beta), — em substituição ao Linux Mint 17.3 Cinnamon, — deixou um “mistério”, desde o Sábado, 20 Ago. 2016:

Os pontos de montagem previamente padronizados, — “E”, “F”, “Home1”, “Linux1”, “Linux3”, “Linux4”, — não podiam ser acessados.

10:57 - Isso ficou evidente ao abrir o Dolphin, — com as configurações “herdadas” do antigo Linux Mint 17.3 Cinnamon, — e não ser possível exibir sua “página inicial”, pelo antigo ponto de montagem em “/media/flavio/F”.

Dispositivos com os nomes corretos, no painel lateral do Dolphin, associados a novos pontos de montagem

10:57 - No entanto, ao clicar nos “dispositivos” no painel lateral do Dolphin, — todos com as “etiquetas” (Label) corretas, — a montagem se realizava sem nenhum problema, — porém, através de pontos de montagem duplicados, nomeados como “E1”, “F1”, “Home11”, “Linux11”, “Linux31”, “Linux41”.

Hipótese de superposição


À primeira vista, essa duplicação parecia resultar da sobreposição de dois métodos diferentes de montagem automática, — supostamente utilizados ao mesmo tempo:

Montagem automática pelo KDE


Montagem automática de partições, como “mídias removíveis”, nas Configurações de sistema do KDE

10:39 – Tinha sido ativada montagem automática das partições adicionais* de documentos “E”, “F” (Fat32), “Home1” (Kubuntu), e partições de sistema dos demais Linux (1, 3, 4).

Este é um recurso típico do KDE:

  • Configurações do sistema → Hardware → Dispositivos removíveis → Habilitar montagem automática → [x] Montar automaticamente no início da sessão

Essa configuração do KDE vem sendo usado há muitos anos, no Kubuntu, — e mais recentemente, também no KDE Neon User Edition, — embora (ainda) não tenha funcionado no Debian testing “Stretch” KDE.

* Por “adicionais”, entendam-se, — partições que não pertencem ao sistema (“/” ou “/home”), — pois estas já estão no arquivo “/etc/fstab”, por padrão.

Montagem “automática” no Cinnamon


Comandos para montagem de partições adicionais — herdados dos “Aplicativos de sessão” do Cinnamon

No antigo Linux Mint 17.3 Cinnamon, não existia esse recurso, — e a solução mais simples tinha sido a montagem de partições adicionais* por meio de comandos “udisks” em “Aplicativos de sessão”, — para serem disparados no início de cada sessão:

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

10:42 – Percorrendo mais algumas Configurações do sistema, deparou-se aquela “herança” do Linux Mint 17.3 Cinnamon, — incorporada, agora, em uma seção do KDE equivalente aos “Aplicativos de sessão”:

  • Configurações do sistema → Espaço de trabalho → Iniciação e desligamento → [x] Aplicativos iniciados automaticamente

com os comandos “udisks” para montagem dessas 6 partições adicionais*.

* Por “adicionais”, entendam-se, — partições que não pertencem ao sistema (“/” ou “/home”), — pois estas já estão no arquivo “/etc/fstab”, por padrão.

Hipótese rejeitada


A primeira sessão do Linux Mint 18 “Sarah” KDE (Beta) instalado estendeu-se até depois do meio-dia

10:20 - Esses comandos “udisks”, — presentes desde antes da instalação, — com certeza foram executados já no boot inicial, às 10:20.

12:38 - No entanto, a montagem automática pelas Configurações de sistema do KDE só deveria fazer efeito a partir do primeiro Reboot, e consequente início de (nova) sessão, — o que só aconteceu bem mais tarde, depois do meio-dia.

Às 10:57, portanto, ainda não tinha ocorrido nenhuma superposição* dos dois métodos.

* A “superposição” dos dois métodos foi mantida, — nos primeiros 2 ou 3 Reboot, — sem acrescentar qualquer novidade a esse quadro, preexistente. — Os comandos “udisks” (herdados do Cinnamon) só foram deletados no final da tarde, às 16:45.

Pausa


Alteração provisória do caminho (path) para os pontos de montagem das partições no arquivo “/home/.conkyrc”

A duplicação dos pontos de montagem, — com os “certos” inacessíveis, e os “errados” funcionando, — não chegou a ser nenhum desastre, nem causava grandes prejuízos.

Foi necessário alterar a “página inicial” do Dolphin, adaptar a configuração do Conky e do Wine etc., — mas, nada que impusesse largar tudo mais, para resolver com urgência.

Alteração provisória do caminho (path) para oos pontos de montagem no “Mapeamento de unidades” do Wine

Desse modo, o assunto pôde ficar de molho, por alguns dias, para observação das pastas do sistema e pesquisa sobre “pontos de montagem” no Linux.

A ideia não era solucionar “de qualquer modo”, — seja o “mistério”, seja o eventual “incômodo”.

O que interessava, era “normalizar” a situação. — O Mint KDE não difere do Kubuntu ou do KDE Neon, em sua estrutura, — e não havia motivo para aceitar, como inevitável, qualquer solução diferente.

Observações - Sexta (26)


Opção “Montar todas as mídias removíveis no início da sessão” tornava inútil desmarcar “Linux2” e “Home2”

Uma última série de observações foi realizada uma semana depois, na Sexta (26).

16:51 - A primeira observação refere-se à montagem das partições “Linux2” e “Home2”, — desnecessária, uma vez que são as pastas “/” e “/home” do próprio Mint, já incluídas (por default) no arquivo “/etc/fstab”, — apesar de estarem desmarcadas na configuração de “dispositivos” do KDE.

O erro estava na opção “Montar todas as mídias removíveis no início da sessão”, — que tornava inútil desmarcar as partições “Linux2” e “Home2”, — e por isso precisava ser desabilitada.

Os pontos de montagem apresentam-se como “pastas” dentro de “/media/USER/

17:12 - Também chamaram atenção as datas dos pontos de montagem em “/media/flavio/”, — onde aparecem como “pastas”, dentro da “árvore” de arquivos da partição do sistema:

As pastas originais, — “E”, “F”, “Home1”, “Linux1”, “Linux3”, “Linux4”, além do Pendrive “Linux Mint 18 KDE 64-bit”, — apresentavam-se datadas das 15:49 do dia 18.

Nessa data e horário, foi carregado pela última vez o antigo Linux Mint 17.3 Cinnamon, — logo após a gravação da imagem ISO do Mint 18 no Pendrive, — para montar e examinar seu conteúdo.

Tratava-se, portanto, da última vez que essas “pastas” foram utilizadas para montagem das respectivas partições.

As pastas “E1” e “F1”, — pontos da efetiva montagem de partições Fat32, — assumiam a data “epoch”.

Trata-se de 1º Jan. 1970, — a “data inicial” dos sistemas Unix, — convertida em horário local (UTC -03:00).

Hipótese: — Partições Fat32 não mantêm datação compatível com a dos sistemas Unix.

As pastas “Home11”, “Linux11”, “Linux31” e “Linux41”, — uma vez montadas, — assumiam datas específicas:

  • Home11: 20/6, às 21:38 → Aplicação co comando “mount --options remount,rw /” em  “Recovery mode” para recuperação de privilégios no Kubuntu (“Linux1”)
  • Linux11: 08/8, às 19:00 → Última atualização de Kernel do Kubuntu (“Linux1”)
  • Linux31: 28/6, às 12:44 → Antepenúltima atualização de Kernel do Debian (“Linux3”)
  • Linux41: 08/8, às 21:02 → Última atualização de Kernel do KDE Neon (“Linux4”)

Sinais de que a pasta “/mnt/” nunca foi usada para pontos de montagem

17:16 - Um exame da pasta “/mnt/” mostrou um conjunto de apenas 6 partições, — todas datadas de 29 Jan. 2016 (instalação do antigo Linux Mint 17.3 Cinnamon), — e que não corresponde ao atual particionamento dos discos rígidos.

Isso, com as atuais partições, — “E”, “F”, “Home1”, “Linux1”, “Linux3”, “Linux4” (ou suas “duplicatas”), — montadas.

Ficava claro, portanto, que a pasta “/mnt/” há muito tempo não é atualizada, — porque nunca foi utilizada como caminho para a montagem de partições, — nem no Mint 17.3, nem agora no Mint 18.

20:50 - Enfim, foi reiniciado o Linux Mint 18 KDE, — após desmarcar a montagem automática de todas as partições “adicionais”, — para um exame das sub-pastas em “/dev/disk/”:

  • /dev/disk/by-id/
  • /dev/disk/by-label/
  • /dev/disk/by-path/
  • /dev/disk/by-uuid/

Nenhuma irregularidade na pasta “/dev/disk/by-label/”

Em “/dev/disk/by-label/”, 8 pastas, — correspondentes às 8 partições de sistema e de documentos, — todas com data e hora do início da sessão atual.

Nenhuma grande irregularidade na pasta “/dev/disk/by-id/”

Em “/dev/disk/by-id/”, 41 pastas, — correspondentes a todas as 16 partições (Swap inclusive), mais os discos rígidos em si mesmos, e as partições estendidas, e a unidade de CD/DVD, — todas com data e hora do início da sessão atual.

Com exceção da unidade de CD/DVD, a cada disco ou partição correspondem 2 entradas, — uma começando por “ata-Maxtor” / “ata-Samsung”, outra por “wwn-”, — ao que consta, um identificador “world wide”, sem qualquer indicação de constituir anomalia.

Um tema para estudos, mas, — por si só, — sem relação aparente com o problema inicial.

Nenhuma grande irregularidade na pasta “/dev/disk/by-path/”

Em “/dev/disk/by-path/”, 12 pastas, — uma para cada disco rígido, e 10 referentes apenas ao segundo HDD, — todas com data e hora do início da sessão atual.

As pastas referentes ao segundo HDD incluem a partição estendida, e mais, — ao que parece, — uma partição “sdb2” que há muitos anos deixou de existir.

Um mistério curioso, mas que, — por si só, — não oferece qualquer perspectiva de “explicar” o problema inicial.

Tudo normal na pasta “/dev/disk/by-uuid/”

Em “/dev/disk/by-uuid/”, 16 pastas, com “nomes” velhos conhecidos, — correspondentes às 16 partições de sistema, documentos e Swap, — todas com data e hora do início da sessão atual.

Pasta “/media/flavio” apenas com os pontos de montagem “fantasma”

Por fim, a pasta “/media/flavio”, — agora, sem qualquer partição montada, — exceto “/” e “/home” via “/etc/fstab”, por UUID.

Aparecem, agora, apenas as 6 partições adicionais, — não-pertencentes ao Linux Mint, — e mais o Pendrive “Linux Mint 18 KDE 64-bit”.

Todas com a mesma data e hora da última sessão do antigo Mint 17.3, — e nenhuma duplicação.

Conclusão


Deletando as pastas dos pontos-de-montagem “fantasma” com o comando “rmdir”

A conclusão dessas observações é de que os antigos pontos de montagem, — datados da última sessão do Mint 17.3, — eram o único fator claramente inútil.

Não tiveram qualquer uso, desde então, — não davam qualquer acesso às partições, — e sua presença forçava o sistema a criar novos pontos de montagem, com acréscimo do dígito “1”, para diferenciá-los.

Passadas mais 24 horas, — para assentar as ideias, — foram simplesmente deletados.

Para isso foi utilizado o comando “rmdir”, — remover pasta (diretório), — com privilégios de Administrador:

su → (senha)
cd /media/flavio
ls → (listar as “pastas” = pontos de montagem)
rmdir E
rmdir F
(etc.)

A partir daí, os novos pontos de montagem passaram a ser criados, automaticamente, com os nomes corretos das etiquetas (label) das partições, — “E”, “F”, “Home1”, “Linux1”, “Linux3”, “Linux4”.

Uma vez comprovada a solução, voltou a ser configurada a montagem automática das partições, — a “página inicial” do Dolphin voltou a ser encaminhada para “F”, — e o Conky e o Wine voltaram a ser ajustados para os caminhos tradicionais.

_________
Publicado em 30 Ago. 2016, às 6:02; e desenvolvido até 2:00 de 31 Ago. 2016.

— … ≠ • ≠ … —

Linux Mint



Kubuntu & KDE


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 Synapticalterado” 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

Desestimularatualizaçõ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 assustadorexplica 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 “EditarPolí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 “EditarPreferê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