Instalei o MX Linux 23 "Libretto" KDE

      Operating System: MX Linux 23
    KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.103.0
            Qt Version: 5.15.8
        Kernel Version: 6.1.0-10-amd64 (64-bit)
     Graphics Platform: X11
            Processors: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz
                Memory: 15.5 GiB of RAM
    Graphics Processor: Mesa Intel® UHD Graphics 630

Pensei muito em fazer um “upgrade” (sem reinstalar) – em vez de apenas instalar o MX-23 “em cima” do MX-21 – mas acabei optando por uma prática diferente, muito “particular”, e à qual já estou habituado:

  • Instalei o MX-23 em uma “partição provisória” – testei (ok) – e “movi” para a partição onde estava o MX-21 (aproveitando sua /home, com todas as configurações já feitas)

Fiz um relato dessa experiência – e espero ainda fazer vários acréscimos nas próximas semanas e meses. – Não é nenhum “tutorial”, mas apenas um registro do que fiz (incluindo possíveis erros e falhas), para que no futuro eu possa entender o que tenha feito de “errado”, e corrigir.

Tentei separar 2 coisas – como é o processo de instalação (que muda bastante, a cada 2 anos) – e o que fiz de “diferente” (sem interesse para a maioria dos colegas).

Quem quiser ver as diferenças do “processo de instalação”, pode examinar os registros que fiz da instalação do MX-21 e do MX-19.

  • E sobre essa mania esquisita de instalar numa “partição provisória” – e depois “mover” para a partição definitiva (substituição de uma instalação anterior) – fiz os relatos, nos casos do MX-21 e do PCLinuxOS.

  • Acho que poucos vão se interessar por essa parte, e por isso tentei minimizar essa parte no relato atual.

Acima - A primeira coisa que fiz, foi instalar no MX-21 o pacote “user-installed-packages” – que salva uma lista daquilo que instalei por vontade própria – e que mais tarde, no MX-23, poderá usar essa lista para agilizar a instalação desses pacotes (com direito a revisar, caso a caso).

Acima - No detalhe (cercado de verde), as 2 opções do pacote: – Listar o que o usuário instalou (no MX-21) – e instalar (no MX-23) os mesmos pacotes, com direito a revisar caso-a-caso.

Naturalmente, também gerei 5 listas de “tudo que estava instalado no MX-21”, usando comandos apt, dpkg e zgrep – de modo que também posso detectar as diferenças feitas pela equipe do MX Linux.

Acimatexto em negrito - Ao iniciar a ISO Live, é automaticamente selecionada a 3ª linha do Menu – Idioma (Localização), Teclado, Fuso horário – pois desse modo, a sessão Live já começará personalizada – e isso se transmitirá à instalação no computador (com direito a mudar alguma coisa, no Instalador).

Terminadas essas configurações, o Menu seleciona “iniciar a sessão Live” (1ª linha do Menu).

  • Ignorei as “Opções Avançadas” – que oferece ótimos recursos, exclusivos do MX Linux. – Ainda não explorei esses ótimos recursos, que são bastante complexos, para quem não conhece… mas recomendo, para quem tiver curiosidade de conhecê-los. Apenas, prefiro avançar 1 passo de cada vez, e optei por (ainda) não mexer com eles.

Acima - Aceitei a opção de “lidar pessoalmente com o particionamento” – pois eu já tinha criado minha “partição provisória” (Linux13). – Tive de selecionar também a partição EFI, caso contrário, o Instalador se recusava a avançar.

Para escolher os pontos de montagem que queremos atribuir a cada partição, basta clicar na seta (ou triângulo) apontando para baixo. – No caso da partição EFI, colei “/boot/efi”, que copiei do aviso de que isso era exigido.

Desmarquei a opção de “Arquivo Swap” (Swap File), para manter o padrão que adotei nas outras 11 distros. – A sessão Live montou automaticamente a partição Swap – mas na instalação final, isso ficou de fora (mas é simples e fácil incluir manualmente, depois).

Acima - Aceitei o hostname “mx”, pois não quis alterar para “Linux12” (que já existia: MX-21), para evitar qualquer problema de duplicidade (não sei se haveria problema: só quis ser prudente).

Aproveitei para descartar o SMB (SaMBa), pois não tenho “rede local” – só 1 PC solitário, ai ai…

Acima - Confirmei as opções já feitas de Idioma (Localização), Fuso horário – e a opção de hora em formato “24h” (odeio esse negócio de AM, PM). – Aceitei o padrão UTC no “relógio do sistema”, pois “usar hora local” só faz sentido para quem “dualboota” Windows (não é o meu caso).

Em “Avançado” (Advanced), desmarquei cups, pois faz mais de 20 anos que me desfiz da minha última Impressora. – (Carro, TV, Impressora, são 3 sanguessugas que sacudi do cangote, Delzulivre!). – A opção “Imprimir em PDF” / “Exportar como PDF” continua à disposição (e as lojinhas de conveniência, também).

Acima - Ativei a criação da “conta Rute”, digo, Root – sempre faço isso! – Foi muito útil, quando descobri que $ sudo nano não pode editar /etc/hosts e /etc/hostname. – Precisei usar su e comandar # nano, para poder fazer isso.

Também habilitei o Login Automático (Autologin), para entrar direto na sessão KDE – e “Save Live desktop changes”, para preservar na instalação final tudo que eu tinha alterado na sessão Live.

  • Na sessão Live, instalei Synaptic, gnome-screenshot e ttf-mscorefonts – e não precisei fazer isso de novo, depois de instalado.

A instalação no PC já estava em 93% ou 96% – e nesse momento fez uma pausa, para que eu pudesse me arrepender de alguma coisa, e voltar, e alterar.

  • Depois que cliquei em Avançar (Next), gastou mais 6 minutos instalando e configurando o Grub, pois o padrão é “detectar outros OS” (e há muito tempo desisti de desabilitar esse os-prober em sessões Live de instalação, de qualquer distro).

Acima - Tratei imediatamente de desmarcar a opção “Reinicializar automaticamente ao fechar o Instalador” (no alto) – pois em geral, tudo que você “salvou” na sessão Live vai para o espaço – e adotei o hábito de verificar se já salvei tudo em Pendrive.

  • Ok, o Live MX Linux garante que vai preservar tudo na pasta /home criada no PC – mas prudência e canja de galinha, não fazem mal a ninguém.

Note que, durante todo o processo, o Instalador do MX Linux oferece 2 abas, no painel à esquerda: – Help, e Live Log. – A experiência já me ensinou que é fundamental acompanhar o Help, o tempo todo, e ler todas as dicas mostradas ali, com a máxima atenção.

O MX Linux oferece inúmeros recursos inexistentes no Debian – e na maioria das outras distros que já experimentei – e quando lidamos com ele, é perigoso achar que “já sabemos o que significa”… com base no que vimos em outras distros.

  • E mesmo lendo o Help, é perigoso achar que “já entendi” (com base na experiência com outras distros). – Muitas vezes, a explicação do Help pode ser confusa, e entendermos errado – como aliás, em todas as outras distros. – Desenvolvedores costumam mergulhar tão profundamente nas linguagens de programação, que quando tentam explicar alguma coisa em Inglês (ou Português), raramente conseguem se comunicar de modo a serem claramente compreendidos pelo comum dos mortais – sejam os mortais, engenheiros, médicos, ou meros ignorantchos. :sweat_smile: – E no MX Linux a coisa é muito mais perigosa, pois implementa coisas que “não vimos antes” (em outras distros)… mas usam +/- as mesmas palavras. Todo cuidado é pouco.

Acima - Ao inicializar o MX Linux instalado no PC, minha primeira providência foi entrar no MX Tweak >> Outros, e “Habilitar a montagem de drives internos por usuários não-Rute”, ops, não-Root.

Significa, simplesmente, montar partições “adicionais” – as que não pertencem ao OS – sem exigir senha.

Tento isso no Debian, desde 2009, e confesso que nunca consegui! (Ok, já tem uns 2 anos que não tentei mais).

  • Me refiro a “não usar o fstab para isso”. – O Debian é a única distro, em que ainda uso o fstab para montar as partições “adicionais”. – Em todas as outras 11 distros, consegui a montagem de partições “adicionais”, apenas clicando pelo Dolphin, e habilitando a montagem automática pelo KDE System Settings >> Hardware >> Removable Storage >> Removable Devices (Dolphin e KDE System Settings usam uDisks2, para fazer isso). – Quando o Debian exige senha, tudo isso deixa de funcionar, ou monta partições “adicionais” não-Writable.

Acima - Depois que testei a nova instalação do MX Linux 23 KDE, abri o /etc/fstab do antigo MX-21, copiei as linhas referentes às partições /home e Swap – e colei no /etc/fstab do MX-23.

(Sim, volta e meia faço backup dos arquivos /etc/fstab [y otras cositas más] de todas as distros. – Agora, usei um backup de Dezembro do ano passado).

Fiz isso pelo Mageia. – Uma das boas coisas de fazer “multiboot” de várias distros, é poder usar umas, para editar os arquivos de sistema de outras – sem a necessidade de rodar sessões Live Pendrive, a toda hora.

Acima - O Grub do MX Linux 23 assumiu a prioridade de boot no UEFI Bios. – Pelo Mageia, usei o comando efibootmgr para devolver a prioridade ao Grub do openSUSE (meu Menu de Inicialização) – e aproveitei para atualizar o Grub do Mageia (meu Grub de reserva).

Acima - Agora que configurei o MX Linux 23 para usar a partição /home da instalação anterior (MX-21), ele já inicia com todas as configurações anteriores – Wallpaper, 2 Conky’s etc.

  • Nos “Lançadores” (Painel KDE), ficou um buraco vazio, onde deveria aparecer o ícone do Chrome, que ainda faltava instalar. – Também faltavam mais algumas coisinhas.

Acima - Faltava liberar as portas para o KDE Connect do celular. – Depois disso, bastou pedir emparelhamento (pelo celular), e aceitar (pelo MX-23), para baixar as fotos da instalação.

Acima - Uma das inúmeras personalizações do MX Linux complicou minha tentativa de desabilitar os-prober. – Pedi ajuda no Fórum, e rapidamente os colegas (inclusive desenvolvedores) indicaram o que eu precisava fazer. – E ali mesmo, já decidiram como tornar isso mais claro para os usuários, numa próxima atualização.

Acima - Corrigi o “nome da máquina”, de “mx” para “Linux12”.

  • $ sudo nano não pode editar /etc/hostnames e /etc/hosts. – Para isso, tive de usar su e em seguida # nano.

Acima - Eu poderia usar o pacote user-installed-packages para instalar meus pacotes preferidos, pela lista que ele mesmo gerou no MX-21 – mas eu prefiro usar sempre o Synaptic, para manter um Histórico unificado de todas as instalações / atualizações / remoções, com direito a pesquisar o histórico de cada pacote.

  • Do Histórico do Synaptic, só ficaram fora, a instalação inicial do próprio Synaptic e do gnome-screenshot, pelo apt, ainda na sessão Live – e a instalação inicial do Chrome (pelo apt) e do GoogleEarh (pelo dpkg).

Acima - No MX-21, eu ainda usava o widget Weather “1”, que funcionava bem com KDE antigo. – Removi, e instalei o Weather “2”, que funciona com KDE mais atual.

Conclusão

Estas são apenas alguns registros da instalação e configuração do MX Linux 23 “Libretto” KDE – sem complicar com aquela mania de instalar numa “partição provisória”, depois “mover” para a partição “definitiva” (onde estava o MX-21), e tudo mais que não interessa à maioria dos colegas.

O relato mais completo está aqui:

(Como disse, ainda vou editá-lo nas próximas semanas e meses, para tentar melhorá-lo e torná-lo mais claro, talvez mais simples, e mais completo).

entao meu mano vc recomendaria o mx linux pra alguem que quer um sistema leve,pq eu sei que tem a versao fluxbox e xfce,estou no ubuntu mais queria algo mais leve,pq nao gosto do gnome,nao acho tao bonito e ainda e pesado,pensei no zorin lite so que a performance ruim nos benchmarks do dio me deixam com um pe atras,gostaria de testar o manjaro e testar algo arch based,se puder me recomendar alguma

Hj eu tenho instalado, graças ao Debian que conseguiu ficar uma verdadeira carroça no meu Dell optiplex 740(tanto XFCE quanto LXDE), eu admito que queimei a língua ao ter um certo preconceito com os non-systemd kkkkk essa distribuição como a maioria das remasters mostra que usar distribuição base e pra quem e masoquista ou gosta de dor de cabeça
Cheguei a testar só a windflower na VM e tive dor de cabeça mas não coloco como fator pois não era direto na máquina(não me recordo se subi um live na época)… Isso me deixou preocupado ao testar a distribuição mas hj superou as espectativas kkkkkk principalmente na instalação de software de terceiros e ferramentas, quem dera ver outras distribuições fazem o básico perto do MX, aprendi com o tempo que visual e só uma besteira pra quem gosta de perder tempo mas criar praticidade e coisa que só vi no MX

Eu tenho recomendado o MX Linux, ultimamente, para quem já tem experiência com os “Buntus” (inclusive, Mint e KDE Neon), ou já tem experiência com o Debian – pois aproveita o que já sabe sobre o apt, sobre os pacotes existentes no “mundo .deb” etc.

O MX Linux é mais “leve” do que o Debian e os “Buntus” em geral – pois instala menos pacotes e ativa menos serviços, por padrão. – Eis o que observei – comparando várias distros com KDE:

RAM usage 10 min uptime (iddle) - just 1 sample

Void             878 MiB
PCLinuxOS        921 MiB
Slackware        940 MiB
MX Linux         940 MiB    --- average 967 MiB, for previous 6 samples
Redcore        1,001 MiB
Manjaro        1,031 MiB
Neon           1,049 MiB
Arch           1,059 MiB
Mageia         1,068 MiB
Fedora         1,139 MiB
openSUSE       1,210 MiB
Debian         1,211 MiB

Se você escolher o MX Linux com Xfce ou com Fluxbox, será ainda mais leve.

Não conheço o Zorin – nunca instalei, nunca utilizei no dia-a-dia.

O Manjaro foi a 1ª distro “não-Debian” e “não-Buntu” que instalei – após 8 anos usando apenas Kubuntu, Debian, Mint, KDE Neon – e gostei muito, desde o primeiro momento.

Mas… tive 3 ou 4 “desastres” e problemas +/- sérios, logo nas primeiras semanas e meses. – Achei fácil consertar, pois bastava pesquisar algumas palavras chaves, para encontrar a solução no Google. – Cabe a você fazer seu próprio teste, para ver se o Manjaro lhe agrada, e se você se sentirá à vontade enfrentando possíveis problemas.

Hoje, eu sei como evitar aqueles problemas no Manjaro, e a instalação atual já está há 2 anos sem me dar nenhum susto. – Não uso o Pamac-GUI, nem o Plasma-Discover, nem Flatpaks, nem pacotes Snapd. – Instalei só um punhado de pacotes do AUR; e gerencio os pacotes só com comandos do pamac-cli e do pacman.

(Também não uso placa de vídeo, nem Bluetooth, não instalo games, tenho só 1 Monitor – e isso também ajuda muito a evitar problemas).

Aquele primeiro Manjaro (Janeiro 2017), troquei pelo Arch Linux – instalado pelo antigo instalador gráfico Revenge Installer (hoje chamado Zen Installer) – e usei por 2½ anos, sem problemas.

Hoje, existem instaladores mais populares, mas nunca experimentei usá-los para instalar o Arch. – No final de 2019, experimentei instalar o Arch pelo “método clássico” (por comandos), e deu certo. – Foi assim que instalei o Arch no meu PC atual, e nunca tive problemas nesses 2¾ anos.

Nunca experimentei outras distros da “base-Arch”, então não posso falar delas.

É possível que você goste do Arch, mas o MX Linux é bem mais fácil, para começar.

Não tenho tido problemas com distros não-SystemD – desde que elas “já venham prontas”… rs

Comecei a instalar o Slackware KDE by AlienBOB desde Agosto 2017, e nunca tive de lidar com seu “sistema init”. – Na época, eu nem registrava isso no meu “Quadro comparativo”. – Minha dificuldade sempre foi (e continua sendo), apenas o gerenciamento de pacotes e atualizações.

Experimentei o Devuan MATE e Xfce em Novembro 2017, e só o que não gostei, era de não ter uma ISO com KDE. – Logo que lançaram uma ISO KDE “beta”, instalei (Fevereiro 2018), e nunca tive de lidar com seu “sistema init”. – O único problema foi quando lançaram a ISO KDE “final”, e ao atualizar a instalação pré-existente “quebrei o KDE” – mas foi fácil reinstalar o KDE no Devuan, e não tive mais problemas.

Comecei a experimentar o PCLinuxOS em Dezembro 2017, e o único problema foi o Grub “gráfico”, que dava crash no Instalador (os-prober com 11 distros em dualboot). – Optei pelo Grub “texto”, e driblei o problema. – No novo PC, em 2020, zero problema, pois comecei pelo PCLinuxOS, e ainda não havia nenhuma outra distro para stressar o Grub (e o hardware também era muito melhor). – Nunca tive de lidar com seu “sistema init”.

Com o MX Linux, foi a mesma coisa: – Nunca tive de lidar com seu “sistema init”. – A dificuldade, em Junho 2018, é que não consegui instalar o KDE “100%” (mas também não tentei muito). – Será que o “não-SystemD” dificulta lidar com KDE Plasma? Pode ser! Até já ouvi falar alguma coisa sobre isso, anos atrás, e depois não ouvi mais falar isso. – Mas é comum distros evitarem ISOs KDE, porque isso exige muito trabalho. Veja o Mint, que abandonou o KDE, por falta de equipe e de tempo para lidar com ele. – Quando finalmente lançaram a ISO MX-19.2 Beta 2, instalei e nunca tive problemas.

Eu só precisei lidar com “sistema init”, quando instalei o Void, em Novembro 2019, pois também não havia ISO com KDE. – Fiz a instalação básica (via instalador), e depois instalei o KDE por comandos, como se fosse a 2ª parte de uma instalação “clássica” do Arch. – Aí, sim, aprendi a usar alguns comandos do Runit, para ativar alguns serviços, e vinculá-los para iniciarem no Boot ou ao carregar o DE.

Mas isso, também precisa ser feito ao instalar o KDE no Arch Linux “BTW” – usando comandos systemctl.

Não precisei lidar com o “sistema init” do Redcore, em Junho 2022, porque oferecia ISO com KDE. – O problema que tive, foi causado por falta de espaço em disco (para as compilações), numa grande atualização – e depois disso, ainda não consegui resolver o impasse: – Ficou uma “tarefa pendente”… mas “a tarefa foi destruída” (“Task was destroyed but it is pending”). Sempre que pesquiso, encontro 300 páginas sobre Python3, e nada sobre Redcore / Gentoo / emerge / sysiphus.

Portanto, só precisei lidar com “init” no Arch e no Void – ou seja, quando se tratava de instalar um DE “na unha” – e é tão fácil fazer isso em um, quanto no outro·