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).

4 curtidas

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

1 curtida

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

3 curtidas

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.

1 curtida

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·

1 curtida

Este tópico foi fechado automaticamente. Novas respostas não são mais permitidas.