Translate

segunda-feira, 23 de maio de 2016

Live KDE Neon Plasma (Wayland) Developer Edition Git-Unstable

Live KDE Neon (Plasma) Developer Edition (unstable branches) 5.6.90, — não “Plasma Wayland”

Esta sessão “Live USB” do KDE Neon Plasma (não-Wayland!) Developer Edition (Git-Unstable) foi carregada às 17:44 de 22 Mai. 2016, e se estendeu até às 21:29 do dia 27, com duração total de 123 horas e 45 minutos, sem “crashes” ou falhas, — “erros: zero”, — até onde é dado a um usuário leigo perceber.

  • Foi precedida de outra sessão, — mera sondagem, — também sem erros, interrompida após 9 horas para recomeçar de modo mais organizado.

Apenas, não foi possível carregar a sessão “Plasma Wayland”, — nas duas vezes, o Login só pôde ser feito para sessão “Plasma”.

Feita essa ressalva, nunca vi um Linux funcionar com tamanha perfeição, — nem em “Live USB”, nem depois de instalado.

Não foram feitos upgrades, — que no 5º dia da sessão “Live USB” (27 Mai.), já somam 234 pacotes, segundo o Synaptic. — Trata-se, portanto, de uma experiência “congelada” no estado do KDE Neon em 20 Mai. 2016: — “plasma-wayland-devedition-gitunstable-20160520-2117-amd64.iso” (não há imagens i386).

Após um primeiro “sudo apt-get update”, foram instalados Shutter e Synaptic.

Pelo Synaptic foram instalados:

  • LibreOffice (pt-br, Writer, Calc)
  • Conky, curl
  • Psensor, lm-sensors, fancontrol, hddtemp
  • Chromium, chromium-codecs-ffmpeg-extra
  • Gimp, ttf-mscorefonts-installer
  • pyRenamer

KDE Neon


O KDE Neon não é uma “distribuição” (“distro”) Linux. — Começou como um “acesso imediato” às mais novas tecnologias KDE, tão logo os pacotes são liberados, — fundado “sobre” o Ubuntu 15.10.

Numa simplificação grosseira, você tem um KDE “rolling release”, — em cima de uma “distro” estável (ciclo periódico), — inicialmente, Ubuntu 15.10.

Em “KDE Neon upgrades to 16.04 LTS” (14 Abr. 2016), Jonathan Riddell antecipou-se em 1 semana ao lançamento do Ubuntu 16.04, ao anunciar a página Download KDE Neon, com imagens ISO Live / Install “daily-built” fundadas sobre o Xenial, contendo apenas KDE Frameworks e KDE Plasma, para contribuidores e usuários dispostos a testá-las.

Às 17:50 do dia 27 Mai. 2016, a página de download oferece imagens ISO datadas das 8:06 ~ 11:44.


Pede-se aos usuários um feedback sobre sua experiência com o KDE Neon User Edition Tech Preview, respondendo a algumas perguntas básicas: — Qual a ISO e data (“date stamp”), como a mídia foi gerada, se enfrentou problemas no Boot, na sessão Live, na Instalação, depois de instalado etc.

→ Quem já tem o Ubuntu 16.04 instalado, pode encarnar os Transformers, por comandos no Terminal. “Basta” instalar “neon-desktop”, acrescentar alguns repositórios, e assim por diante. Não explorei esse caminho, pois não tinha motivo para brincar com o Kubuntu 16.04 recém instalado. Em tempo: KDE Neon frisa que essa operação não acrescenta uma camada ao Kubuntu, — por não serem compatíveis, — mas simplesmente o substitui.

KDE Neon Plasma Wayland


Mais recentemente, em “Plasma Wayland images go daily” (4 Mai. 2016), Jonathan Riddell anunciou que, — dado o desenvolvimento da infraestrutura do projeto KDE Neon, — o Plasma Wayland passava a ser oferecido em cima de suas atualizações diárias.

“It uses packages built from KDE Frameworks and Plasma Git master branches and has a default session of KWin running as a Wayland compositor”.

A primeira parte da frase repete a descrição anterior do “KDE Neon”, — com quase as mesmas palavras.

Na segunda parte da frase, explicita que, — no “KDE Neon Plasma Wayland”, — o Kwin roda “como compositor Wayland”.

Às 17:50 do dia 27 Mai. 2016, a imagem ISO disponível datava da noite da véspera, — parece haver uma defasagem regular de cerca de 12 horas entre a liberação diária do “KDE Neon” e a do “KDE Neon Plasma Wayland”:


→ Também neste caso, quem já tem o KDE Neon instalado, pode adicionar o Plasma Wayland pelo comando “sudo apt install plasma-workspace-wayland”, sem necessidade de baixar imagem ISO e reinstalar. Também não explorei esse caminho, até porque não tenho KDE Neon instalado.

Caçando sarna


Esta última imagem ISO era, de longe, a que prometia mais “emoções”, — pelo menos, para um mero usuário, que não entende lhufas dessa conversa toda, — e foi a escolhida para um “teste de trabalho em Live USB” (sem intenção de instalar… em tese).

A escolha baseou-se unicamente na máxima quantidade de pedras e espinhos:

  • Um projeto novo, que nem chega a ser “distro”,
  • declaradamente mal-testado,
  • em versão não destinada a “usuário”,
  • na opção “instável”,
  • e por cima disso tudo, com algo ainda tão controverso como o Wayland.

Sem dúvida, estava nos limites extremos do “não-confiável”, — em especial, para um usuário leigo total.

Exatamente o tipo de coisa que nunca havia experimentado. O Kubuntu 14.04, p.ex., — com toda sua reputação e confiabilidade, — só fui instalar meses após o lançamento, depois de assentada a poeira dos bugs iniciais.

Mas rodar um “projeto” Linux em sessão Live USB não tira pedaço. — E é um estímulo para aprender alguma coisa.

Até agora, essa brincadeira já me fez tomar conhecimento de várias coisas, — da existência de um “servidor X”, da virada da Canonical para o “Mir”, da ampliação do papel do “Kwin” etc., — e poderá me deixar um pouco menos perdido, num eventual cenário futuro, onde venha a ter de pesar prós & contras entre Kubuntu vs. KDE Neon.

De “Wayland”, propriamente, apenas começo a fazer uma ideia, — mas não sei exatamente qual a diferença entre esta sessão “KDE Neon Plasma” (que já caminha para 120 horas) e uma sessão “KDE Neon Plasma Wayland” (opção que ainda não consegui carregar no Login).

Na prática, portanto, fica provisoriamente adiado o último item da lista de pedras & espinhos, — até que consiga carregá-lo. — Suponho que o que pude rodar foi o equivalente à penúltima opção de imagem ISO:  — Developer Edition Git-Unstable Branch

Problemas: Zero


Desconfiguração mínima no Dolphin: 1 minuto para tornar a ocultar partições não-utilizadas

Quanto ao resto, — não ser uma “distro”, estar muito pouco testado, não se destinar a usuários, rodando pacotes “instáveis”, — após 120 horas de sessão Live contínua, foram registrados tão poucas falhas “visíveis” a um leigo, que equivalem a “zero falhas”:

  • Uma única, pequeníssima, perda de configuração do Dolphin, — a certa altura, o painel de “Locais” voltou a exibir partições que havia ocultado, — o que pode até ter sido causado por algum clique descuidado. Uso muito o “right-click” naquela área, para abrir uma partição em “nova aba”, mas qualquer descuido pode reexibir partições ocultas, ou desmontar etc.
  • Um ou dois casos de fechamento do Kate, — evento tão silencioso e discreto, tão imperceptível, que talvez eu mesmo tenha fechado, sem me dar conta. Ainda tenho a tendência de esquecer quando há 2 ou mais documentos abertos, e fechar o aplicativo, em vez de fechar uma aba.

Fato é que não recebi nenhum aviso de “crash”, nem de “erro”, “fechamento inesperado”, nada, — nem detectei falhas não-notificadas, — após 5 dias de sessão contínua, em trabalho constante.

A meu ver, isso é um grau de “perfeição”, superior ao do Kubuntu 16.04 LTS instalado há 1 mês, — o que me deixa com a preocupante vontade de substituí-lo pelo KDE Neon Developer Edition (unstable branches) Plasma Wayland.

Erros & erros


“wayland-errors” e “xsession-errors” no KDE Neon após quase 120 horas de sessão contínua

Naturalmente, faço algumas cópias do arquivo “~/home/.xsession-errors” para uma pasta do HD. Tinha 1,1 MiB no dia 23 (23:00); umas 12 horas depois, 1,5 MiB no dia 24 (11:30).

Agora, dia 27 (16:18), está com 4,9 MiB, porém a última modificação data da véspera, — sinal de que nenhum erro foi registrado ao longo de umas 8 horas de trabalho intenso.

“Erros”, portanto, sempre existem. — Na sessão Live Kubuntu 16.04 de 22~23 Abr. 2016, quase sem falhas perceptíveis, o arquivo “xsession-errors” alcançou 2,3 MiB em 31 horas.

Já o arquivo “~/home/.wayland-errors” ao final do 5º dia, continua com apenas 1,8 KiB, e data das 17:43 do dia 22, — quando a tela de Login oferecia as opções de sessão “Plasma (Wayland)” ou apenas “Plasma”. — Parece conter a explicação de por quê não foi possível carregar uma sessão “Plasma-Wayland”:

startplasmacompositor: Starting up...
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
No backend specified through command line argument, trying auto resolution
QObject: Cannot create children for a parent that is in a different thread.
(Parent is KWin::LibInput::Connection(0x1195d20), parent's thread is QThread(0x1154e10), current thread is QThread(0x10e8ed0)
QObject: Cannot create children for a parent that is in a different thread.
(Parent is KWin::LibInput::Connection(0x1195d20), parent's thread is QThread(0x1154e10), current thread is QThread(0x10e8ed0)
QObject: Cannot create children for a parent that is in a different thread.
(Parent is KWin::LibInput::Connection(0x1195d20), parent's thread is QThread(0x1154e10), current thread is QThread(0x10e8ed0)
QObject: Cannot create children for a parent that is in a different thread.
(Parent is KWin::LibInput::Connection(0x1195d20), parent's thread is QThread(0x1154e10), current thread is QThread(0x10e8ed0)
QObject: Cannot create children for a parent that is in a different thread.
(Parent is KWin::LibInput::Connection(0x1195d20), parent's thread is QThread(0x1154e10), current thread is QThread(0x10e8ed0)
QObject: Cannot create children for a parent that is in a different thread.
(Parent is KWin::LibInput::Connection(0x1195d20), parent's thread is QThread(0x1154e10), current thread is QThread(0x10e8ed0)
kwin_core: Failed to initialize compositing, compositing disabled
kwin_core: The used windowing system requires compositing
kwin_core: We are going to quit KWin now as it is broken
startplasmacompositor: Shutting down...
xprop:  unable to open display ''
xprop:  unable to open display ''
startplasmacompositor: Done.

Shutter


Mensagens de “erro” do Shutter, a cada vez que se renomeiam seus arquivos fora dele

Afora isso, apenas mensagens de “erro” do Shutter, — na verdade, crises de ciúme, — a cada vez que seus preciosos screenshots são renomeado pelo Dolphin ou pelo Gwenview.

Registro esse detalhe do Shutter, apenas como lembrete, — para futura observação no Linux Mint, e reavaliação de qualquer coisa similar que tenha registrado em outros testes Live USB. — Esta foi a primeira vez que comprovei a causa & efeito desse “erro” do Shutter.

Para evitar esse estresse, parece haver pelo menos 2 caminhos:

  1. Usar o próprio Shutter para visualizar e renomear suas capturas de tela, — embora não ofereça algumas comodidades do Gwenview, a que já me acostumei.
  2. Escolher a opção “Descartar”, em cada aviso desses, do Shutter, para que o respectivo arquivo deixe de fazer parte de sua “sessão”.

Bailando com Discover


Discover em Live Kubuntu: “meia-trava” ao redimensionar a janela

Embora não tenha sido utilizado para instalar pacotes no KDE Neon, o Plasma-Discover foi aberto, e apresentou comportamento muito diferente do observado no Kubuntu Xenial beta / beta2 / released.

Em Live Kubuntu 16.04 LTS, a “animação” inicial do Plasma-Discover ocupava quase 50% da CPU, — alternando entre quase 100% do Core0 / quase 100% do Core1, — e tentativas seguidas de cliques & letras no campo de Busca demoravam quase 1 minuto para surtir efeito (permitir digitação).

Uso alternado dos processadores pelo Plasma-Discover no Kubuntu 16.04 LTS

O efeito palpável, no Kubuntu, era certa “lentidão seletiva”, — uma “meia-trava”, — além de visível aquecimento dos processadores, CPU, Placa Mãe.

Ciclo de 30’’ no uso de ambos os processadores, simultaneamente, pelo Plasma-Discover no KDE Neon

No KDE Neon Plasma (não-Wayland!), a “animação” inicial do Plasma Discover ocupa quase 100% de ambos os processadores, — simultânea e continuamente, com pequenas pausas cíclicas a cada 30’’ — porém o aplicativo responde de imediato a qualquer ação (clicar, digitar, arrastar, redimensionar janela), o que resulta em notável sensação de “leveza”.

Arrastar Discover no KDE Neon, com ambos os processadores 94% ocupados: a janela voa. Quase escapuliu

Além disso, o sistema, como um todo, não dá nenhum sinal de “lentidão”, — muito menos, de “meia-trava”. — Pelo contrário. — Você “pega” a janela do Plasma Discover para arrastar, e baila à vontade com ela, por toda parte. — Praticamente “voa”, como um legítimo “pé-de-valsa”.

Total ignorante dos aspectos técnicos, — nunca tinha prestado atenção em “servidor X”, muito menos em “Wayland”, até a semana passada, — não faço a menor ideia, se isso tem qualquer relação com o assunto. Fica o registro.

Obs.: O Menu do Discover ficou “invisível” (detalhe à direita, acima). É preciso adivinhar que está ali, e clicar, para ver que há um retângulo, e abri-lo.

Vale notar que na sessão Live Kubuntu 16.04 beta2, em 10 Abr. 2016, o Plasma-Discover era “KDE Frameworks 5.18.0 / Qt 5.5.1”, — enquanto o observado agora, em Live KDE Neon Plasma (não-Wayland!), é “KDE Frameworks 5.22.0 / Qt 5.6.0”.

Perfil do aquecimento dos processadores pela “animação” do Plasma-Discover durante 4 minutos, no KDE Neon

O aquecimento de CPU, MB, Processadores no KDE Neon parece nitidamente maior, — porém os registros de Temperatura com Plasma-Discover no Kubuntu 16.04, foram pouco detalhados, com a única exceção do dia 10 Abr. 2016, — o que dificulta uma comparação mais acurada.

Uso de Memória, CPU e aquecimento em Live KDE Neon com 25 abas abertas no Chromium

Botando fogo


Não foi planejado, — mas, bem que poderia.

Terminada a configuração inicial (17:40~19:00) da sessão KDE Neon Plasma (não Wayland!), no dia 22, uma das primeiras providências foi pesquisar mais sobre “Wayland”, — que imaginava ser coisa recente, devido à controvérsia quanto à sua adoção, — mas o volume de resultados relevantes foi tão abundante que, sem perceber, abri 27 páginas em abas do Chromium, à medida em que ia selecionando as mais promissoras.

De acordo com o Conky, — parcialmente ocultado pelo Chromium, num print sobre outra coisa, — às 20:28, estavam ocupados 3,63 dos 3,85 GiB da Memória RAM.

Infelizmente, só lembrei de documentar o Psensor e o KSysguard, 10 minutos mais tarde (20:38), quando já havia fechado 2 páginas, — e me dei conta da situação.

Como não explodiu nem pegou fogo, não havia necessidade de perder a pesquisa, — bastava não abrir mais nada, e tratar de examinar a colheita já realizada. — Ler, favoritar (ou não), fechar, de modo seguro, gradual e lento.


O exame do material terminou às 21:47, — quando restaram apenas 2 abas no Chromium, e o uso de Memória baixou a 0,9 GiB, segundo o KSysguard, — ou 1,12 GiB, segundo o Conky, cuja configuração (ainda) não desconta Buffers e Cache.

O uso de apenas 0,9 GiB, — com 2 abas abertas no Chromium, — é um caso excepcional, provavelmente graças ao deslocamento de nada menos que 1,8 GiB de dados para o Swap.

Início e final dos dias


A experiência com outros “testes de trabalho em Live USB” já tinha sugerido que, — uma vez alocado maior uso da memória Swap, — a tendência é baixar muito pouco.

Dessa vez, não foi diferente, de acordo com as capturas de tela feitas ao encerrar os trabalhos de cada dia, — fechando todos os aplicativos, exceto Dolphin (em geral 2 abas), Conky, Psensor, Ksysguard, Shutter, — e antes de iniciar o trabalho no dia seguinte:

  • Dia 23, às 3:24, após fechar aplicativos: RAM: 0,69 / Swap: 1,1 GiB
  • Dia 23, às 6:06, antes de iniciar o dia: RAM: 0,67 / Swap: 1,1 GiB
  • Dia 24, à 1:05, após fechar aplicativos: RAM: 0,84 / Swap: 1,0 GiB
  • Dia 24, às 8:09, antes de iniciar o dia: RAM: 0,85 / Swap: 1,0 GiB
  • Dia 25, à 1:44, após fechar aplicativos: RAM: 0,79 / Swap: 1,4 GiB
  • Dia 25, às 8:47, antes de iniciar o dia: RAM: 0,83 / Swap: 1,4 GiB
  • Dia 26, às 2:45, após fechar aplicativos: RAM: 0,78 / Swap: 1,2 GiB
  • *** Shutter elevou uso da RAM para 1,3 GiB ***
  • Dia 26, às 9:52, antes de iniciar o dia: RAM: 1,2 / Swap: 1,2 GiB
  • Dia 26, às 10:30, após corrigir o Shutter: RAM: 0,88 / Swap: 1,2 GiB
  • Dia 27, à 0:05, após fechar aplicativos: RAM: 0,89 / Swap: 1,4 GiB
  • Dia 27, às 8:05, antes de iniciar o dia: RAM: 0,90 / Swap: 1,4 GiB

O problema com o Shutter, — que elevou a ocupação da Memória RAM ao documentar o encerramento na madrugada do dia 26, — foi causado por algumas experiências feitas com ele, e ficou para ser resolvido no dia seguinte, quando as “experiências” foram desfeitas.

Por uma “questão de honra”, não foi encerrada a sessão (Logout / Login), — coisa, aliás, que a experiência também já demonstrou ter pouco efeito, quanto ao uso de memória Swap.

Observações qualitativas


Nenhum problema com as inúmeras “camadas” (layers), “notificações” etc., que normalmente tornam o Facebook problemático, — em especial, no Debian, mas não apenas.

Pouco ou quase nenhum aquecimento dos processadores ao abrir o Facebook em várias abas do Chromium, — em comparação com o observado no Kubuntu 16.04 e anteriores (HD), Linux Mint (HD) e outras distribuições testadas em Live USB, — porém não foram localizados tais registros para comparação.

Pouco ou quase nenhum aquecimento dos processadores ao assistir longos vídeos no Youtube e no Facebook, — porém não foram localizados registros do aquecimento em outras distribuições, para comparação.

Download da ISO e gravação do Pendrive


Download do “plasma-wayland-devedition-gitunstable-20160520-2117-amd64.iso” no Kubuntu

O download do KDE Neon foi feito na noite 20 Mai. 2016, — por isso a “date stamp”: — “plasma-wayland-devedition-gitunstable-20160520-2117-amd64.iso”.

Gravação do Pendrive com a “plasma-wayland-devedition-gitunstable-20160520-2117-amd64.iso” no Mint

A gravação da midia (Pendrive) foi feita por comando “dd”:

sudo dd if=/PATH/FILE of=/dev/sd? bs=8M

Onde o “PATH” foi copiado diretamente do Dolphin, por “Ctrl-L” → “Ctrl-C”; — “FILE” foi copiado do próprio arquivo, por “F2” (renomear) → “Ctrl-A” (selecionar o nome completo) → “Ctrl-C”; — e ambos colados no bloco de texto, para compor o comando específico, a cada gravação.

No caso específico do meu sistema, o Pendrive é identificado como “sdc”.

O comando assim montado foi copiado para o Terminal, e executado.

Durante o processo, nenhuma indicação de “andamento” é apresentada, — apenas o LED do Pendrive pisca sem parar, — e só no fim os resultados surgem no Terminal, de uma vez.

Os resultados exibidos no Terminal foram então copiado para o bloco de texto, — onde também se preservam resultados anteriores, — para a eventualidade de algum dia querer comparar vários casos.

1ª sessão KDE Neon — de improviso


17:40 – (21 Mai. 2016) – A primeira tentativa de carregar o KDE Neon não conseguiu ultrapassar a tela de Login.

A opção padrão — sessão Plasma Wayland — “faz que vai”, mas retorna ao Login.

Isto, sempre deixando em branco o campo da senha.

18:34 – Na segunda tentativa, em vez de “Plasma Wayland” (default), foi escolhida sessão “Plasma” (2ª opção) → senha em branco → carregou o ambiente gráfico, com o wallpaper do KDE Neon.

Vem sem nenhum programa de captura de tela, — “PrtScn” é tecla morta.

“Error while moving old database out of the way. AppStream cache update failed” no “apt-get update”

18:42 – sudo apt-get update (não pede senha).

Apesar da mensagem “Error while moving old database out of the way. AppStream cache update failed” (também registrada em Live Kubuntu 16.04), — “apt-get” instala o Synaptic.

O Synaptic exige “consertar aquivos quebrados”, para instalar Spectacle, — mas instala Shutter e Chromium-browser, sem problemas.

Configuração da tecla de atalho PrtScn para captura de tela pelo Shutter no KDE Neon

19:18 – Primeiro screenshot, — com o Relógio ainda indicando 22:18 (UTC).

19:34 – Ao tentar abrir um arquivo “.odt”, mensagem de erro do Ark (!). — Não havia LibreOffice.

19:38 – Instalação do LibreOffice Writer pelo Synaptic.

19:42 – Instalados Conky e curl pelo Synaptic. — Faltou registrar a instalação de Psensor, lm-sensors, hddtemp, fancontrol.

“sudo sensors watch” no Terminal, para conferir os sensores instalados no KDE Neon (ainda com horário UTC)

19:48 – sudo sensors detect

19:52 – sudo sensors watch

19:58 – Configurado o Fuso horário (São Paulo).

19:59 – Conky posto a rodar com as configurações copiadas do Kubuntu 16.04 (HD), apenas alterando o cabeçalho para “KDE Neon”.

Repositórios habilitados no KDE Neon Plasma Wayland

20:06 – Verificação dos repositórios do KDE Neon Plasma Wayland Developer Edition (unstable branches), no Synaptic.

As configurações do Conky ainda não estavam ajustadas para encontrar as partições.

As configurações para deixar o Conky transparente, — apenas transplantadas do Kubuntu, — não deram resultado no KDE Neon Plasma.

Às 20:33, o Psensor foi ajustado para intervalos de 1 segundo, — um exame dos prints anteriores mostrava muitas diferenças de Temperatura e uso de CPU, em relação ao Conky, — mas parece que esse ajuste ainda foi insuficiente para resolver o problema. — Há dois ajustes de tempo no Psensor, — uma no Gráfico, outra nos Sensores.

Uso da Memória RAM após fechar todos os demais aplicativos para encerrar a 1ª sessão Live USB com KDE Neon

Essa 1ª sessão Live KDE Neon, — sem planejamento, e muito mal documentada, — foi encerrada às 3:50 do dia 22.

O “shutdown” leva à tela azul clara “KDE Neon 5.6.90” (igual à que antecede o Login), e só desliga de fato com um “Enter”.

Se a opção escolhida for “Restart”, penso que esta seja a hora de retirar o Pendrive (ou DVD), — ainda que não haja mensagem neste sentido.

Deixando o Pendrive no slot, ele será ignorado, — como ocorreu na primeira tentativa, lá no início: — Foi para o Grub, aproveitei para entrar no Linux Mint, — e o Mint não assinalava o Pendrive, sequer para poder solicitar uma “retirada segura”.

Nos testes recentes, com várias distros em Live USB, o Kubuntu, — se não me engano, — também se distinguiu por não parar no final do Restart, para pedir que retire o Pendrive, — que passava a ser ignorado pela Bios, indo direto ao Grub.

2ª sessão KDE Neon Plasma em Live USB


Opções “Plasma Wayland” e “Plasma” no Login to KDE Neon Developer Edition (Unstable), em horário UTC

A 2ª sessão Live USB do KDE Neon foi carregada às 17:44 do dia 22, e já caminha para completar 120 horas.

Partindo das observações realizadas na véspera, esta 2ª sessão “Live” pôde seguir um roteiro mais objetivo e organizado, — com melhor documentação de cada passo.

17:43 - Opções: “Plasma (Wayland)” e “Plasma”.

17:44 - Tela inicial do KDE Neon

17:45 - Configurado o Fuso horário (São Paulo).

17:46 - Configurada a aparência do Relógio.

17:47 - Configurada a aparência do Terminal (Konsole).

17:48 - “apt-get” não encontra Shutter, nem Synaptic.

17:50 - “apt-get update” → “Error while moving old database out of the way. AppStream cache update failed”.

17:52 - “apt-get” instala Shutter e Synaptic.

17:54 - Configuração do atalho PrtScn → “shutter -f”.

Tela inicial do KDE Neon Developer Edition (Unstable)

17:55 - 1º print do Shutter: ~/home/pictures/Desktop 1_001.png.

18:00 - Aberto o Dolphin para montar F:\, e poder configurar o Shutter para gravar diretamente no HD, em formato JPEG, com nome automático no padrão “YYYY-MM-DD_HH-MM-SS_Kn.jpg”.

Dolphin configurado no KDE Neon

18:11 - Dolphin configurado.

18:13 - Aplicado Wallpaper.

18:16 - Colocadas na “/home” as configurações do Conky (“.conkyrc”), guardadas da sessão anterior.

18:22 - Instalação parcial do LibreOffice (PT-BR, Writer, Calc) pelo Synaptic.

18:28 - Configuração do Teclado (PT-BR + tecla de acesso ao 3º nível).

A configuração “Restaurar sessão salva manualmente” cria a opção de saída ”Salvar sessão”

18:37 - “Restaurar sessão salva manualmente”. → “Salvar sessão”. — Esse recurso do KDE agiliza bastante o trabalho, permitindo abrir automaticamente o Dolphin com várias abas, nas mesmas pastas usadas na véspera, além do Psensor e do KSysguard, — em janelas nos mesmos formatos, tamanhos e posições.

Uma alternativa é a opção “Restaurar a sessão anterior”, — que vai depender de um encerramento sempre atento e organizado, ao final de um dia cansativo.

Em sessões “Live USB”, é claro que não se trata de desligar o computador, — a menos que você crie um Pendrive com “persistência”. — Mas é útil quando se usa o recurso de “encerrar sessão” (Logout / Login), para solucionar alguma dificuldade.

Foi bastante usado, nos “testes de trabalho em Live USB” dos últimos meses, — em especial, com o Kubuntu 16.04 (beta, released). — Mas no caso do KDE Neon, após 120 horas, ainda não foi sentida qualquer necessidade de “encerrar sessão”. — Transcorre tudo na mais perfeita serenidade.

• No caso do Chromium, Firefox e LibreOffice, — cada um com suas próprias configurações de como devem se comportar ao abrir, — “Restaurar sessão” não funciona muito bem. — É preciso fechá-los antes de encerrar a sessão, — ou irão reclamar de que foram “encerrados abruptamente”.

• No caso do Psensor, é preciso desabilitar a opção “Restaurar posição e tamanho da janela”, — que na verdade, restaura o padrão original.

• O Gimp também tem suas próprias configurações, — Edit → Preferences → Tool options → Save tool options on exit / Save tool options now, — que mantêm a fonte, tamanho, cores etc., agilizando o trabalho ao reabri-lo, daí por diante.

Desabilitando “Pesquisa de arquivos” no KDE Neon

18:38 - Desabilitada a “Pesquisa de arquivos”. — Hábito adquirido há algum tempo, no Kubuntu, e reforçado ao ver o Baloo consumindo CPU.

Montagem automática de partições ao iniciar uma sessão do KDE Neon

18:40 - Montagem automática de algumas partições, — E:\, F:\, Debioso, Primoroso, — ao iniciar uma sessão. Também é uma medida prática para agilizar o trabalho, — embora o KDE Neon ainda não tenha causado nenhuma necessidade de “Encerrar sessão”.

18:41 - Logout / Login experimental, para testar as configurações de sessão. — Faltava configurar “Turn on NumLock on Plasma startup”.

18:45 - Adicionado ao Painel o widget “Show desktop”.

18:49 - Instalados conky-all, curl, psensor, lm-sensors, hddtemp, fancontrol pelo Synaptic.

18:52 - Instalado Chromium-browser + codecs-ffmpeg-extra pelo Synaptic.

18:55 - Instalados Gimp + ttf-mscorefonts-installer pelo Synaptic.

18:58 - sudo sensors detect.

Por volta das 19:00, portanto, a sessão Live USB do KDE Neon estava com a configuração praticamente completa, no essencial, — inclusive, os aplicativos necessários para o trabalho e atividades pessoais de uma semana inteira, — após uma “interrupção” de apenas 1h20min, entre o final da tarde e o início da noite de Domingo.

• Intervalo para colocar em dia a comunicação na web.

Ajuste do intervalo de tempo do Psensor para 1 segundo

20:02 - Ajuste do intervalo de tempo na aba “Gráfico” do Psensor, de 2 para 1 segundo. — Até então, registravam-se discrepâncias gritantes em relação às Temperaturas de Core0 e Core1 indicadas pelo Conky. — É necessário outro ajuste de 2 para 1 segundo, também na aba “Sensores”.

— … • … —

Kubuntu



Testes de trabalho em “Live USB”


Postado por Mboaba às segunda-feira, maio 23, 2016 0 comentários
Marcadores: , , , , , , , ,

sexta-feira, 20 de maio de 2016

Baloo consumindo CPU no Kubuntu 16.04 LTS

Consumo de CPU pelo baloo_file_extractor logo após a instalação do Kubuntu 16.04 LTS

24 Abr. 2016 - Terminada a instalação do Kubuntu 16.04 LTS (14:51), o computador foi reiniciado (14:56), e começaram a ser feitas as configurações e ajustes (15:04).

Nos primeiros 41 minutos, foram abertos, — e logo fechados, — apenas diálogos e programas relativamente “leves”:

  • Spectacle ← em 2º plano, chamado eventualmente
  • Dolphin ← único a permanecer aberto
  • Descobridor (plasma-discover)
  • KDEWallet ← chamado pelo Descobridor para autenticação
  • gerenciador de Widgets do Plasma
  • Monitor do sistema (KSysguard)

E foi aí (15:45) que se revelou um “consumo” extraordinário de CPU, — acima de 50%, alternando entre 100% do Core0 ou 100% do Core1, — além de uma ocupação de 1,5 GiB da Memória RAM sem motivo aparente.

A Tabela de Processos do Monitor do sistema indicou “baloo_file_extractor” como o responsável pela façanha, enquanto KSysguard e Spectacle consumiam 1% da CPU, cada, — e nesse momento estava aberto apenas o Dolphin, minimizado.

Consumo de CPU por baloo_file_extractor após Logout / Login no Kubuntu 16.04 LTS

Entre 15:56 e 15:58, foi encerrada a sessão (Logout / Login), e ao abrir novamente o Monitor do sistema (KSysguard), ele indicou uso de apenas 0,82 GiB da Memória RAM (sem Dolphin), — porém o mesmo consumo excessivo de capacidade da CPU.

Após abrir o Dolphin, a ocupação da Memória RAM passou para 0,90 GiB, — ainda bem longe, portanto, do 1,5 GiB anterior.

A função do Baloo é a indexação e busca de arquivos, — não só pelo nome, como por data, por grau de “avaliação”, por dados Exif das fotos (ao que se diz), — e a intenção era deixá-lo fazer seu trabalho.

O elevado consumo da capacidade da CPU não parecia interferir nas demais tarefas, — exceto, talvez, como potencializador, em vários pequenos crashes, que nem estavam incomodando tanto assim, — e de bom grado deixaria o computador ligado de um dia para outro, se isso pudesse acelerar a conclusão da indexação, e mais rápido melhorar minha experiência com o Kubuntu daí por diante.

Acontece que por volta das 17:37 foi configurado o Psensor, — e indicou que a temperatura da CPU já andava oscilando acima de 60ºC, com picos até perto de 65ºC, — coisa que não costuma acontecer, mesmo ao assistir um longo vídeo no Facebook, por exemplo.

Como deixar ligado e dormir tranquilo, com essa ameaça de incêndio?

Acontece, também, que o Baloo esteve ativo desde 2014 (Kubuntu 14.04), pelo menos, — e antes dele, o Nepomuk, — mas isso jamais proporcionou mais do que buscas bastante simplórias, por nome de arquivo e, de modo muito limitado, algum conteúdo.

Aliás, as opções de busca no Dolphin* são extremamente limitadas, — no máximo, “tipo de arquivo”, “esta semana”, “este mês”, “este ano”, — nada que se compare aos recursos de busca oferecidos no Explorer do velho Windows XP (cuja indexação desabilitei, e nunca fez falta).

Algum controle do processo de indexação pelo Baloo, — p.ex., poder personalizar um limite ao uso da CPU, — talvez encorajasse deixá-lo prosseguir à vontade.

Mas, — usuário desde o Kubuntu 8.04, — nunca deparei com nenhum controle desse tipo, antes, e tampouco pude encontrar agora.

O que uma pesquisa rápida na web mostrou foram bugs e soluções, — p.ex., verificar se o processo realmente avança, ou se atolou em algum ponto, rodando no vazio, sem sair do lugar. — Mas isso exigiria tempo, estudo, e pode muito bem ser feito em outra ocasião.

Finalização do processo baloo_file_exctactor pelo KSysguard, no Kubuntu 16.04 LTS

A decisão tomada, portanto, foi a de interromper o processo.

Uso da CPU sem o processo baloo_file_exctactor, no Kubuntu 16.04 LTS

Encerrado o Baloo, o “consumo” de CPU despencou de imediato, e logo baixou a temperatura da CPU, Core0, Core1, Placa Mãe.

Desmarcando a opção “Ativar a pesquisa de arquivos”, nas Configurações do sistema

Por via das dúvidas, também foi desativada a “Pesquisa”, nas Configurações do sistema.

Desde então, — passado quase um mês, — nenhuma dificuldade de Pesquisa foi percebida no Kubuntu 16.04 LTS, utilizado dia-sim-dia-não para o trabalho regular.

Nenhuma perda de desempenho na pesquisa de arquivos, em relação ao Kubuntu 14.04 dos últimos 2 anos.

Nos dias 20 e 21 Mai. 2016, foi efetuado um teste de pesquisa de arquivos, — nas mesmas partições, com as mesmas palavras-chave, — pelo Kubuntu, pelo Mint e pelo Windows XP, — e foram encontrados os mesmos resultados, sem qualquer diferença entre os três sistemas.

Portanto, as vantagens da indexação pelo Baloo, — que devem existir, com toda certeza, — são algo de que nunca me beneficiei, até o momento.

Caso contrário, já teria percebido a diferença.

Resta supor que tais benefícios dependem de algum aprendizado, configurações específicas etc., — ao passo que o consumo de CPU vem por default.

(*) 10 Jun. 2016 - Pesquisa com recursos realmente “avançados” é oferecida pelo Krusader e pelo Konqueror, e após 6 semanas ainda não deu qualquer indício de capengar por falta do Baloo, — que por princípio indexa apenas a “/home”, — enquanto que todos os arquivos de trabalho (normalmente solicitados para busca), há mais de 6 anos estão nas partições “F:\” e “E:\” (FAT32), do antigo Windows.

(**) 19 Jun. 2016 - Por default, a “Pesquisa de arquivos” abrange a “/home”, — que, neste caso, é principalmente backup da partição “F”, — e contém cerca de 150.000 arquivos, em cerca de 6.500 pastas e subpastas, num total de aproximadamente 117 GiB.

— … • … —

Kubuntu


Postado por Mboaba às sexta-feira, maio 20, 2016 3 comentários
Marcadores: , , , ,

domingo, 1 de maio de 2016

Desapareceu o Menu do Linux Mint 17.3 Cinnamon

Desaparecimento do Menu e do Lançador no Painel do Linux Mint 17.3 Cinnamon, — e mensagem de erro

O Linux Mint 17.3 Cinnamon foi instalado no dia 18 Jan. 2016, — e 2 semanas depois o Menu desapareceu.

Problema nenhum, para quem sabe tudo de Linux, — mas muito chato para um simples usuário, — e aconteceu à 0:32 de um Sábado, 30 de Janeiro.

A mensagem de erro não foi muito esclarecedora, para quem não é expert.

Você decide pesquisar, enfrentar o problema, — mas, como abrir o Chromium, ou o Firefox? — Além do Menu, também sumiu o “Lançador”, onde havia colocado atalhos para meia dúzia de programas de uso mais frequente.

Painel → botão direito → Adicionar miniaplicativo

Applets com menus de todos os tipos para instalar no Painel do Linux Mint 17.3 Cinnamon

Não é tão difícil abrir o navegador. — Você clica com o botão direito numa área desocupada do Painel, seleciona “Adicionar miniaplicativos ao Painel”, e dentro dele seleciona a aba “Applets disponíveis online”. — Logo no primeiro “applet” oferecido, você clica em “Mais informações”, — e eis o navegador aberto, para pesquisar uma solução para o problema.

Mas, não adianta instalar nenhum desses inúmeros Menus alternativos, — enquanto não recuperar o Menu do sistema. — Por enquanto, esta é só uma dica de como chamar o navegador, para procurar uma solução.

Editor do Menu (Cinnamon)


Menu → Outros: itens inúteis escondem WhatsChrome e outras coisas úteis

Sei exatamente o quê estava fazendo, — ou tentava fazer, — ao provocar o desaparecimento do Menu.

Tinha acabado de instalar uma cópia antiga do Corel Draw, — e verifiquei que Menu → Outros estava repleto de itens inúteis, — muitos deles já eliminados do Wine, antes mesmo de instalar o Linux Mint 17.3.

O “Windows” do Wine (C:\windows) e todos os seus aplicativos (C:\Program Files) ficam em uma pasta oculta em /home/$USER/.wine, — e se você instala uma nova distro, sem formatar a partição /home, basta instalar e configurar o Wine na nova distro, para continuar usando os aplicativos instalados antes.

O itens do Menu também ficam em pastas ocultas na /home, — e também sobrevivem, se a partição não for formatada.

Resolvi, portanto, “editar” o Menu do Linux Mint Cinnamon, para “desmarcar” a exibição daqueles itens-fantasma, — ou deletá-los de uma vez por todas.

Também queria agrupar os itens restantes na categoria Menu → Wine.

Clique com o botão direito no Menu do Cinnamon e escolha Configurar

Um caminho, para abrir o Editor do Menu do Cinnamon, é clicar com o botão direito no ícone do Menu, e escolher Configurar.

Outro caminho é abrir o Menu → Configurações do sistema → (Preferências) → Miniaplicativos → botão direito no applet Menu → Configurar.

Abertura do Editor do Menu do Cinnamon, a partir da configuração do applet

Por qualquer dos 2 caminhos, você chega ao Editor do Menu, — cuja utilização exige cuidados.

Editor do Menu do Cinnamon, — e dezenas de itens órfãos na categoria “Outros”

Não lembro quantas ações cheguei a tentar, — nem exatamente quais. — A única certeza é de que fiz poucas tentativas, antes de o Menu desaparecer.

É de se supor que o Editor do Menu do Cinnamon funcione para a maioria dos usuários, — a menos que a maioria não use, ou resolva seus casos por outros meios, — mas as exceções são numerosas e persistentes no tempo, a julgar pelos pedidos de socorro e tutoriais encontrados.

O problema não é exclusivo do Linux Mint, — ocorre onde quer que se use o ambiente Cinnamon, — mas não prestei atenção aos tópicos onde era citado o Gnome.

Se você limitar sua busca, no Google, apenas ao “último ano”, — tópicos recentes ou ainda ativos, — já terá material para muitas horas de leitura.

Uma das soluções, frequentemente sugerida, é utilizar uma espécie de “undo”, específica para o Painel do Cinnamon, — abra um terminal, cole e execute esse comando, 1 vez, 2 vezes, 3 vezes etc.:

gsettings reset-recursively org.cinnamon

Várias pessoas agradecem, felizes da vida, — resolveu para elas, — mas outras informam que não solucionou.

Aqui, o uso desse comando apenas desfez 2 ou 3 configurações muito úteis (e bem anteriores ao crash), — até que decidi parar por ali mesmo, e refazer (à mão) o que já tinha desfeito (sem que o problema se resolvesse).

A nova pasta “.config” (à esquerda), — e a antiga, com vários anos de configurações

O que resolveu, — após alguma pesquisa, — foi “remover” a sub-pasta (oculta) .config, dentro da “pasta pessoal” → /home/flavio/.config.

Foi exagero! — Bastava “remover” a sub-pasta /home/flavio/.config/menus, — sem perder todas as configurações de dezenas de aplicativos.

Para “removê-la”, — sem perder todas as outras configurações, — apenas renomeei como .config_b.

Uma vez que essa pasta “pertence” a você mesmo, você pode alterá-la pelo Nemo, — se conseguir abri-lo!, — sem sair da sessão Cinnamon.

Mas não consegui abrir o Nemo, — por isso, a “intervenção cirúrgica” foi realizada a partir do Kubuntu. — Naquela hora, foi muito prático, ter 2 sistemas Linux em dualboot.

Ao reiniciar o computador (ou fazer Logout / Login para iniciar nova sessão), — e não encontrar uma pasta .config, — o Linux Mint Cinnamon cria outra .config, vazia, que logo começa a “povoar”, à medida em que você abre um aplicativo, e outro, e mais outro. Porém, todos com a configuração-padrão.

De imediato, é criada uma nova sub-pasta .config/menus, — e a nova sessão já se inicia com o Menu restabelecido, — tal como era, antes de tentar editá-lo.

Mais tarde, a nova pasta .config foi renomeada .config_c, e a antiga voltou ao seu lugar, com o nome correto.

Então a nova sub-pasta .config_c/menus foi copiada e colada no lugar da antiga .config/menus, — e todas as demais configurações, personalizadas ao longo dos anos, voltaram.

Crash revisitado


Novo crash ao usar o Editor do Menu do Cinnamon

Durante 3 meses, — de 30 Jan. até 30 Abr. 2016, — nunca mais utilizei o “Editor do Menu” do Cinnamon.

Não ocorreu nenhum outro problema embaraçoso. — O Linux Mint 17.03 Cinnamon vem sendo usado, dia-sim-dia-não, para trabalho e atividades pessoais, com toda produtividade e confiabilidade.

Mas, aquelas anotações, prints, bookmarks etc. aguardavam um registro organizado, — e hoje, ao separar o material para publicação, o bicho-mexedor tornou a meter a patinha onde não deve.

Cheguei a tentar, apenas, o mínimo, — desmarcar 1 item-fantasma, depois um 2º item-fantasma, — e… — Crash! — De novo.

Comandos para montagem automática das partições, em “Aplicativos de sessão” (gnome-session-properties)

Felizmente, agora o Dolphin está nos Aplicativos de sessão, — Portanto, já estava aberto, automaticamente, desde o momento em que foi carregado o Linux Mint 17.3 Cinnamon.

Assim, foi possível consertar o novo desastre, sem sair do Linux Mint, — e apenas fazer Logout / Login, para reiniciar a sessão Cinnamon.

Três gerações de “.config/menus”, — antes de 30 Jan., desde 30 Jan., e em 1º Mai. 2016

Foi uma boa oportunidade para testar a hipótese de que não seria necessário mexer em centenas de configurações, acumuladas na pasta .config, — bastaria “remover” a sub-pasta .config/menus.

De fato, isso foi mais do que o bastante, para resolver o problema.

A sub-pasta .config/menus foi renomeada .config/menus_XX_2016-05-01, e ao reiniciar a sessão, — por Ctrl-Alt-Del → Logout / Login, — o Linux Mint Cinnamon criou outra sub-pasta .config/menus, novinha em folha.

E lá estava, de volta, o Menu.

Applet do Usuário, — muito útil para Desligar, Reiniciar ou Encerrar uma sessão no Linux Mint 17.03 Cinnamon

Outra “saída alternativa”, — para Reiniciar, Desligar, ou apenas Encerrar a sessão (Logout), — é pelo “Applet do Usuário”.

Já tinha eliminado (ou, apenas não-incluído?) esse applet do Painel, antes do dia 30 Jan. 2016, — mas a leitura de possíveis soluções para o “crash do Editor do Menu” mostrou sua utilidade. — No mínimo, é um caminho muito mais rápido, do que qualquer outro Menu.

Menus em abundância


Variedade de applets alternativos para substituir o Menu do Cinnamon

Um tipo de resposta muito comum, — quando alguém pede socorro após um crash do Editor do Menu do Cinnamon, — é sugerir que instale um Menu “alternativo”.

E, de fato, é notável a quantidade de opções disponíveis, — mais de 20 Menus “alternativos”, — mas não funcionam, enquanto o Menu original estiver desaparecido.

Midnight-Commander


Midnight-Commander instalado e aberto em sessão CLI

Esta foi apenas uma das situações em que me senti órfão de pai e mãe, — sem Menu, sem nenhum Lançador, para abrir qualquer aplicativo, ou sequer para “Sair”, — pois nos primeiros 7 anos de Linux me concentrei nas soluções GUI, para tocar o trabalho sem muita perda de tempo.

Felizmente, foi uma das situações mais fáceis, — pois consegui abrir o navegador para pesquisar, — e tinha uma segunda distro, em dualboot, para resolver o problema, com todo conforto.

Mas havia alternativas.

1) - Um modo seria fazer Logout, — então usar Ctrl+Alt+F2 para alternar da tela de Login para o Console virtual tty2, logar nele, e fazer tudo por comandos. — Isso é chato, para quem ainda não tratou de se familiarizar, e pode acabar em desastre.

Em algumas distros, a o ambiente gráfico fica no tty1, — em outras, no tty7, — ou em algum outro Console virtual.

A maneira mais simples de descobrir é tentar Ctrl+Alt-F1, — Ctrl+Alt+F2 etc., — até mapear todas as que estão disponíveis, e onde está o ambiente gráfico, ou a tela de Login.

1.1) - Tempos depois, adquiri o hábito de sempre instalar o Midnight-Commander (mc) em todas as distros. — É um gerenciador de arquivos que você pode usar no Console virtual, sem Cinnamon ou qualquer outro ambiente gráfico.

Logado como Root, o mc também pode ser usado para editar arquivos de configuração, como /etc/fstab, numa emergência.

Ao editar pela primeira vez um arquivo (F4), o mc costuma perguntar qual editor você deseja usar. — As opções costumam ser o Nano (o mais simples e amigável), o Vi ou Vim (o mais poderoso, porém um tanto difícil), e o editor interno mcedit.

2) - Tendo outra distro em dualboot, reiniciar a máquina, carregar o Kubuntu e usar o Dolphin.

3) - Outra opção, seria carregar uma sessão Live DVD (ou Live Pendrive), — e usar o Nemo, ou Dolphin etc., a partir dele. — Neste caso, talvez precise usar privilégios de Super-Usuário (Root); para isso, convém se informar das senhas Live da distro que vai usar.

Isso porque, na maioria das distros, o primeiro Usuário criado tem identificador UID=1000, — ou seja, é sempre “o mesmo”, independente do nome utilizado. — Mas se o Usuário da sessão Live tiver identificador UID=999, não poderá alterar nada na /home do UID=1000, a menos que recorra aos poderes de Super-Usuário.

• Solução para o Wine


De algum lugar, provêm os itens-fantasma rastreados pelo Menu do Cinnamon

Parecia fora de dúvida que a solução mais simples e correta para eliminar a multidão de itens-fantasma e outros itens inúteis, na categoria “Outros”, — restos arqueológicos de experiências feitas no Wine, — fosse uma “limpa” nos registros ocultos, preservados na “/home”, que o Menu do Cinnamon limita-se a rastrear.

Chamava atenção, em especial, a pasta:

“/home/.local/share/applications/wine/Programs/”,

— embora outras pastas também sejam indicadas em vários tutoriais e tópicos de foruns, — porque ali se encontravam exatamente os itens (úteis ou inúteis) da categoria Menu → Outros.

Renomeando itens de Menu → Outros na pasta “/home/.local/share/applications/wine/Programs/”

O primeiro teste foi “remover” os arquivos “indesejáveis”, renomeando o sufixo “.desktop” para “.ex_desktop”.

Categoria Menu → Outros expurgada dos itens-fantasma ou sem utilidade

A cada item-fantasma renomeado, imediatamente desaparecia de Menu → Outros o item-fantasma correspondente. — Após essa constatação, a “limpeza” prosseguiu com mais tranquilidade, até eliminar todos.

Obs.: — Esta “solução” (ainda) não funcionou no Kubuntu (3 Mai. 2016).

Restou a pasta:

“/home/flavio/.local/share/applications/wine/Programs/Adobe/Photoshop 6.0/”

que não contém nenhum arquivo com o sufixo “.desktop”.

Foi deletada a pasta-mãe:

“/home/flavio/.local/share/applications/wine/Programs/Adobe/”

e mesmo assim, o item “Adobe Photoshop CS” não desapareceu de Menu → Outros.

Não era mesmo de esperar que desaparecesse, — uma pasta “6.0” não poderia ser a causa de um “CS” no Menu.

Restando 1 único item a eliminar, decidi voltar ao “Editor do Menu” (Cinnamon), e apenas desmarcá-lo.

Tinha comigo uma teoria, — de que o crash decorre de algum “encavalamento” de 2 ou mais ações sucessivas, sem aguardar algum “delay” entre elas, — e não acreditava que 1 única ação simples, como “desmarcar”, causasse problemas.

Funcionamento perfeito do “Editor do Menu” (Cinnamon), quando se faz apenas 1 clique

De fato, não causou, — a “desmarcação” do item Photoshop transcorreu na mais completa paz.

Apenas, o item “desmarcado” efetuou uma cambalhota e saltou para o topo de outros iguais a ele.

Photoshop eliminado de Menu → Outros, no Linux Mint 17.3 Cinnamon

Por via das dúvidas, aguardei ainda alguns minutos, antes de fechar o “Editor do Menu”, — e pelo menos 1 minuto, antes de abrir o próprio Menu → Outros, para ver o resultado.

Funcionou.

• Experimentos & comparações


A adoção de 2 sistemas, — “principal” (Kubuntu) e “alternativo” (Debian, Mint, Kubuntu), — cumpre vários papéis:

  • Segurança — Dispor de uma “Opção B”, em caso de problemas no sistema principal (e vice-versa).
  • Comparação e aprendizado — Não ficar limitado a uma única “distribuição” GNU / Linux, ou a um único “ambiente gráfico”. Por mais que goste do KDE / Kubuntu, ele não é tudo. Tem pontos fracos (como o Menu K), assim como possibilidades pouco evidentes, — “ainda não descobertas”, — e com frequência trago aplicativos ou configurações descobertos no Mint ou no Debian, por exemplo.

Várias experiências com Wine foram tentadas no sistema “alternativo”, — por isso, é na “segunda /home” que se acumularam inúmeras “instalações” (falhadas) de programas antigos do Windows.

Somente as que deram certo no sistema “alternativo”, foram depois aplicadas no sistema “principal”, — cujo Menu permaneceu “limpo”, por esse motivo.

Agora mesmo, em 30 Jan. 2016, o Linux Mint 17.3 Cinnamon, — acabado de instalar 2 semanas antes, — foi utilizado para experimentar a instalação de uma versão antiga do Corel Draw.

A instalação foi um sucesso, — o Wine / Corel abriu os arquivos acumulados nas últimas décadas, em geral “matrizes” de mapas ilustrativos, — mas, por algum motivo (a desvendar), até agora não conseguiu salvar alterações, nem exportar (GIF, JPG) as atualizações dos mapas.

Quanto ao Photoshop, já falharam mais de 15 tentativas de instalar o primeiro “CS”, — ao custo de vários dias de pesquisa e experimentação, — e o acervo acumulado de arquivos “.psd” só aguarda um tempo livre, para ser expurgado em massa, salvo poucas exceções.

• Outros “Editores de Menu”


Itens do Wine no Menu → Achados e perdidos, do Kubuntu

“Editar Menu”, nunca se apresentou como “bicho de sete cabeças”, — mesmo quando o Linux ainda era um mundo misterioso e desconhecido.

Lembro, — ainda não tinha um caderno específico para centralizar anotações, — de editar o Menu no Debian, em um Ubuntu + KDE completo, e com certeza também no Kubuntu.

Mas, tudo isso é muito vago, nebuloso.

Passei, então, ao Kubuntu 16.04 LTS, — instalado há 1 semana, — e tratei de examinar o Menu.

Aliás, “os Menus”, — o “K”, no canto esquerdo, e o “Homerun Kicker”, no canto direito, — cada um com suas funcionalidades.

Ficou evidente a ausência de “lixo”, — não foram feitos “experimentos” com Wine no sistema “principal”, — portanto, não ficaram “restos” na “/home” do antigo Kubuntu 14.04, a serem “herdados” pelo 16.04.

Menu “Homerun Kicker”, no Kubuntu, após eliminar 3 itens dos “Achados e perdidos”

Mesmo assim, havia 3 itens inúteis, — 2 Adobe-fantasma e 1 Macromedia Extension Manager nunca utilizado, — e foi feito um teste.

Right-click no Menu-K ou no Homerun Kicker para abrir o KDE Menu Editor

O “editor de Menu” pode ser chamado tanto a partir do Menu K, quanto a partir do Homerun Kicker. — Testei a partir deste último, só para provocar as chances de algum problema. — Mas não houve problema algum.

KDE Menu Editor

xxx

________
Publicado em 1º Mai. 2016, com 12 imagens.
• Ampliado até 3 Mai. 2016.

— … ≠ • ≠ … —

Linux Mint



Kubuntu & KDE


Postado por Mboaba às domingo, maio 01, 2016 0 comentários
Marcadores: , , , ,
Assinar: Postagens (Atom)