Primeira ISO do Arch Linux com Kernel 5.2 já está disponível
O Arch Linux é uma distribuição Linux desenvolvida com o objetivo de ser o mais simples possível, dando ao utilizador o poder de tomar o maior número de decisões possíveis quanto à sua configuração.
Recentemente foi lançada a primeira ISO do Arch Linux que já vem com o kernel 5.2.
É verdade que depois de conhecer o Arch Linux, facilmente se percebe quais os trunfos desta distribuição. No entanto, a dificuldade está, para muitos, logo na instalação.
Instalar esta distribuição não é propriamente a tarefa mais simples, mas o Pplware disponibiliza um tutorial aqui. Depois de instalada as vantagens são mais que muitas.
Esta é uma das distribuições mais limpas e com menos apps desnecessárias, o que a faz ser usada por muitos, que depois a preparam ao seu gosto e com as suas aplicações favoritas.
Podem também ter esta distribuição dentro do Windows 10.
Está disponível mais uma versão do Arch Linux que desta vez chega com o novo Kernel Linux 5.2. O snaptshot tem a identificação Arch Linux 2019.08.01 e pode ser obtido aqui.
Arch Linux 2019.08.01 apenas para novas instalações
Tal como ISOs anteriores, o Arch Linux 2019.08.01 é direcionado apenas para novas instalações. Esta versão, como é natural, traz todas as atualizações de segurança e bugs corrigidos... logo o utilizador não necessita de atualizar a distribuição após a sua instalação.
Para quem já tem o Arch Linux numa máquina, basta que execute o comando sudo pacman -Syu para proceder à sua atualização.
Este artigo tem mais de um ano
Proponha uma correção, faça uma sugestão
Loading ...
O Arch Linux é para quem gosta de (ou tem paciência para) estar sempre a mexer no computador, para configurar muitos dos aspectos – até para fazer coisas tão simples como uma actualização do sistema.
E, para além disso, (por ser esta uma distribuição “bleeding edge”) de cada vez que se actualiza um sistema com Arch Linux é quase como jogar à “roleta russa” (por a operação em causa poder correr mal)…
Por estas razões,
Se não forem (vocês) utilizadores avançados de – i.e. que já tenham uma boa experiência em – GNU/Linux, nem pensem em começar por esta distribuição, para conhecer esta família de sistemas operativos…
E, comecem antes pelo Ubuntu ou outras distribuições que sejam descritas como “user-friendly”.
Procure por distros que facilmente tenham rollback. Mas de qualquer forma, há distros que são pegar e usar, mas claro, para um uso de utilização comum são excelentes, mas para quem é profissional da área, já não é só necessário instalar um browser e um reprodutor de vídeo.
Nessas condições (profissionais de it), distros mais amigas do dev são necessárias, e Ubuntu é muito mau nisso. Ubuntu é um Windows que por acaso tem um kernel Linux.
Aposto que o Arco (um tipo que costuma comentar aqui) sabe ou tem ideia de como fazer rollback no Arch.
E porque não dar uma volta no Manjaro? Está muito bom!
Nunca percebi bem porque há malta que vai usar um remake do original, isto sem que o original tenha parado no tempo oi se tenha deteriorado…
Mas pronto, o problema que o BlackFerdyPT expôs, no manjaro, é exactamente o mesmo que no Arch, já que é tudo praticamente igual, inclusive gestor de pacotes.
Por que o Manjaro é mais que um remake, ele criou formas de auto-detectar e instalar drivers (seja proprietários ou não), tem facitadores como instalação de pacote de idiomas complexos, mudança de kernel, tudo gráfico… Manjaro é o Ubuntu do mundo Arch… Quem usa Manjaro quer algo out-of-the-box e user-friendly.
Concordo contigo, Daniel.
O Manjaro é uma distro que já vem com tudo pronto. Até a instalaação é bem mais fácil e extremamente rápida. Levei menos de 25 minutos para a o instalar.
Melhor era até o Pedro Pinto explicar como faz ele um rollback, para uma actualização anterior.
Ainda melhor era, imaginemos que por acaso é um pacote que foi actualizado mas que sempre que é usado, trava o sistema. Melhor era fazer um rollback apenas do pacote em questão, mantendo todo o resto do sistema actualizado.
E não esquecer que o pacote pode ter (e normalmente tem) dependências, portanto, a cereja no topo do bolo era um rollback do pacote e suas dependências, para a versão anterior.
Pedro Pinto, ideias?
ARC, ideias?
Pode-se fazer claro. Deixa arranjar tempo 😀
Normalmente as coisas correm mal quando existe um abuso de AUR meio desconhecidas, ou quando se faz um update parcial: sempre pacman -Syu ou (-Syyu), actualizar os mirrors (reflector).
Tb se pode usar o kernel mais antigo (linux-lts) como backup em caso de problemas no boot.
Rollback: timeshift e/ou grsync.
Rollback UMA app para versão anterior:
1- instalar script através aur: downgrade
1.1- exemplo comando: downgrade firefox ( e depois escolher da lista a versão anterior firefox)
2- Usar pacman cache: pacman -U /var/cache/pacman/pkg/pacote-versão_antiga.pkg.tar.xz
Obrigado. Como não conheço, e o que acontece com as dependências?
O pacman á partida trata das deps no entanto se se verificar conflitos vai ter de ser á unha uma a uma no entanto como o archlinux está sempre a actualizar para a ultima versão existente é normal que em poucos dias o assunto esteja resolvido caso contrário usar um snapshot:
https://wiki.archlinux.org/index.php/downgrading_packages
REPARO
O Linux kernel apresentado para este Arch Linux 2019.08.01, é o 5.2.5 e NÃO o 5.2!
NOTA: este é um tipo de tema, que deveria ser DEBATIDO no fórum do Pplware e NÃO aqui!!!
INTRODUÇÃO
Como todos devem saber, o Arch Linux, para álem de ser uma rolling release é ao mesmo tempo DIY (Do It Youself). Assim, devemos ser bastante cuidadosos quando este é actualizado com frequência, e ainda mais quando se instala ou actualiza via repositório de terceiros, ou se quiserem via AUR.
Não deixa de ser VERDADE, que em algumas situações, o sistema em si mesmo pode ficar inoperacional temporariamente, se NÃO existir conhecimentos suficientes para à posteriori serem resolvidos. Por isso mesmo, é da RESPONSABILIDADE do user em Arch Linux, tornar ele mesmo o mais estável possível.
É ASSIM, e NÃO à volta a dar, e eu CONCORDO com essa metodologia apresentada pela equipa do Arch Linux.
Cometer ERROS, é um facto que todos cometemos, mais ou menos e ter cuidado o máximo de tempo, nem sempre é possível. Por vezes, desejamos simplesmente realizar uma actualização do sistema no seu todo, e podemos encontrar por exemplo, o que se denomina por broken packages.
Uma das premissas, que um Arch Linux user tem de ter presente, é que NUNCA deve entrar em PÂNICO, a Wiki do Arch Linux, é a sua melhor fonte de documentação, bem como as man pages.
Arch Linux, exige aprendizagem constante, por isso mesmo, NÃO é considerada uma Distribuição de Linux AMIGAVEL para os users iniciantes, e também por isso mesmo, eu NÃO recomendo o Arch Linux para estes mesmos users. Podem escolher Manjaro Linux ou Endeavour OS (ex Antergos_https://endeavouros.com/), como uma primeira abordagem ao Arch Linux.
1. Downgrade de Pacotes
O método tido como oficialmente recomendado pode ajudar grandemente, se e só se a cache do pacman, não se encontrar clean. Contudo, importa dizer que mesmo que a cache tenha sido esvaziada, ainda assim é permitido e possível a execução do downgrade.
Esta ferramenta (downgrade), ajuda a reverter para um versão mais antiga do pacote escolhido que se encontre disponível, ou em cache ou remotamente, assim esta mesma ferramenta vai verificar a cache local bem todos os servidores remotos, ou se quiserem os repositórios do Arch Linux para as versões mais antigas desse mesmo pacote (uma delicia!!) e desse modo é POSSÍVEL escolher qual a versão antiga desse pacote desejamos instalar.
Vou supor que o pacote downgrade, se encontra instalado na vossa Distribuiçao Arch Linux e vou simular o downgrade para o Firefox, vejamos:
2. Downgrade e sua sintaxe
sudo downgrade [PACKAGE, …] [– [PACMAN OPTIONS]]
[arc@openbox ~]$ sudo downgrade firefox
[sudo] senha para arc:
Available packages:
1) firefox 64.0.2 1 x86_64 (remote)
2) firefox 65.0 1 x86_64 (remote)
3) firefox 65.0 2 x86_64 (remote)
[…]
+ 26) firefox 68.0.1 2 x86_64 (remote)
+ 27) firefox 68.0.1 2 x86_64 (local)
select a package by number:
Basta escolher o numero do pacote e já está feito!!!!
3. RECOMENDAÇÕES
3.1 EVITAR SEMPRE, todo e qualquer upgrade parcial, quer isto dizer, que NUNCA se deve executar, algo similar a: pacman -Sy OU pacman -Sy.
Assim, devemos sempre em PRIMEIRO LUGAR utilizar pacman -Syu, para o sistema ser actualizado e SÓ DEPOIS, utilizar package -S para a instalaçao desse pacote.
3.2 Alguns Blogs e Web Sites, quiçá menos informados ou até mesmo querendo transmitir informações erradas, RECOMENDAM a utilização de pacman -Syu –force. É UM ERRO GRAVÍSSIMO, ficam a saber que a flag (-force), vai ignorar todo e qualquer conflito entre pacotes e ficheiros e tem por consequência apresentar pacotes quebrados e até mesmo colocar o Arch Linux INOPERACIONAL.
3.3 NUNCA deixar de verificar as dependências, quer isto dizer, que NÃO é ACONSELHÁVEL a utilização de pacman -Rdd , como alguns recomendam alegremente!
Ficam a saber, que caso este comando seja executado, qualquer que seja a dependência critica necessária para esse mesmo pacote, que por sua vez é ao mesmo tempo necessária para outro qualquer pacote, vai ser REMOVIDA, e tem por consequência colocar o Arch Linux INOPERACIONAL.
3.4 Com sabem, e MUITAS VEZES FAZEM OUVIDOS MOUCOS, uma das melhores práticas, é a utilização regular de BACKUPS, para os dados mais importantes, ficheiros de configuração, etc.
LEITURA RECOMENDADA
https://wiki.archlinux.org/index.php/Downgrading_packages#Automation
E muito mais havia para dizer…
CORRECÇÃO:
Em 3.1, onde diz:
“Assim, devemos sempre em PRIMEIRO LUGAR utilizar pacman -Syu, para o sistema ser actualizado e SÓ DEPOIS, utilizar package -S para a instalação desse pacote.”
DEVER SER:
Assim, devemos sempre em PRIMEIRO LUGAR utilizar pacman -Syu, para o sistema ser actualizado e SÓ DEPOIS, utilizar package -S para a instalação desse pacote.
Assim, devemos sempre em PRIMEIRO LUGAR utilizar pacman -Syu, para o sistema ser actualizado e SÓ DEPOIS, utilizar package -S para a instalação desse pacote.
Pois é a formatação!!!
package -S package-name
Grrrrr!!!
3.1 EVITAR SEMPRE, todo e qualquer upgrade parcial, quer isto dizer, que NUNCA se deve executar, algo similar a: pacman -Sy OU pacman -Sy.
pacman -Sy package-name OU pacman -Sy.
Arc, foi pelo motivo que descreveste, este: “…Ficam a saber, que caso este comando seja executado, qualquer que seja a dependência critica necessária para esse mesmo pacote, que por sua vez é ao mesmo tempo necessária para outro qualquer pacote, vai ser REMOVIDA, e tem por consequência colocar o Arch Linux INOPERACIONAL.” que os tempos de slackware, Gentoo, Debian e Arch já lá vão.
Não foi uma nem duas nem três, foram variadas, e nas piores alturas (nunca há boas alturas, mas há as más e as péssimas) em que fiquei agarrado.
O problema comum a todas as distros era o “estado” do sistema. Como as dependências são correlacionadas entre pacotes, fazer um downgrade de um pacote atinge outros pacotes, via dependências que entretanto são quebradas.
Daí a invenção maravilhosa, vinda das linguagens funcionais, a preservação do “estado” a todo custo. Tecnicamente não é totalmente preservado, mas está muito perto. Se na tua cabeça saltou algo como Snapshot, não é a solução, ou melhor, é um remendo momentâneo. É demasiado grosseiro, porque move todo o estado do sistema de uma só vez.
O estado da arte é poder isoladamente escolher.
Um exemplo: eu (user:dot) quero o emacs, mas com suporte a gtk2, mas o arc (user:arc), que tbm usa o mesmo computador quer o Emacs instalado com suporte a grk3, não há problema.
E imagina que eu passo a tbm ter suporte a gtk3, tal como o arc, mas não gosto, e faço o downgrade para grk2, o arc não fica a arder.
E isto é um exemplo básico.
Melhor até é poder, sobre o mesmo pacote rescrever condições que se queira, opções de compilação, etc, e fazer isto N vezes, e todas funcionam no mesmo computador sem problema.
A ideia é ter uma pool pacotes e bibliotecas e declarativamente combinar a gosto, portanto, o sistema no seu global mantém o seu estado.
Claro que é muito chato para quem usa, por exemplo, npm, esta porcaria polui o global space. Para manter bom e similares “controlados”, é preciso uma certa ginástica, mas dá.
Caro Dot, agradeço desde já este debate com seriedade nos argumentos, assim vale a pena “conversar” sobre temas raramente discutidos e da máxima importância para os *nixs em geral, na media em que este tema (Rollback, Dependencias e afins) é transversal a todos eles.
É verdade, que quando escrevi “…Ficam a saber, que caso este comando seja executado, qualquer que seja a dependência critica necessária para esse mesmo pacote, que por sua vez é ao mesmo tempo necessária para outro qualquer pacote, vai ser REMOVIDA, e tem por consequência colocar o Arch Linux INOPERACIONAL.”, foi tão ciente desta realidade como ao mesmo tempo pensava que alguém iria debater este tema.
Por isso o meu agradecimento e estou completamente de acordo com a abordagem apresentada por si…e vamos viajar…
O que temos presente aos dias de hoje em *nixs?
A totalidade dos gestores de pacotes existentes hoje em dia (apt, rpm, pacman, FreeBSD Ports Collection, etc.), sofrem quase sempre com o problema que designa no meio, por Destrutive Upgrades.
Quer isto dizer, que sempre ou quase sempre que é realizado um upgrade, seja este para uma ÚNICA aplicação ou para a totalidade do sistema, esse tal gestor de pacotes (NÃO interessa nada qual ele seja), ele vai subscrever os ficheiros que se encontram nesse momento no SO, por outros nas suas versões mais recentes.
E aqui é que COMEÇAM as dores de cabeça!!
Mas, se esses mesmos pacotes forem sempre compatíveis com as versões anteriores, obviamente este problema NÃO se coloca.
Só que, este desiderato, nem sempre acontece, ou raramente acontece, para ser mais rigoroso. No entanto, todos deveríamos saber que é precisamente o CONTRÁRIO que acontece, e assim os pacotes NÃO são compatíveis com as versões anteriores!!
Vamos para o meu exemplo do Firefox…
Suponhamos que eu actualizei o Firefox (esqueçam que eu uso Arch Linux, Manjaro Linux e Debian Linux, isso não é relevante para o debate), e que o gestor de pacotes DECIDE que também necessita de uma versão mais nova e actualizada do GTK. Então se o GTK a ser instalado, NÃO for compatível, com as versões anteriores, com toda a certeza outras aplicações, PODEM ser interrompidas de forma repentina e LIMBO!
Em *nix, o busílis da questão, são as múltiplas dependências externas, desde a sua criação…NADA a fazer por agora.
(Outros SOs sofrem também deste problema, segundo rezam as “crónicas”)
NOTA: este famigerado paradigma, está a mudar, segundo dizem as más línguas, para o lado dos *nixs!!!
Além disso, este tipo de upgrades que criam instabilidades nos *nixs, DIFICULTAM grandemente o rollback ou até mesmo o upgrade, a menos que o user (pois à la “unhaca”) ou o gestor de pacotes em causa, faça um backup da totalidade dos ficheiros a serem substituídos, a realização do undo ou do upgrade, NÃO vai ser fácil.
Também devemos ter presente, que o gestor de pacotes vigente nessa Distribuição de Linux, se encontra ocupado a subscrever a totalidade dos ficheiros que pertencem a um pacote especifico, o sistema entra de forma temporária num estado de inconsistência, no qual esse pacote pode ou não funcionar de forma correcta.
A regra diz que, um qualquer upgrade de um determinado pacote, faz com que a versão mais antiga desse mesmo pacote, desapareça por completo. Contudo, e acontece algumas vezes, o gestor de pacotes da nossa Distribuição de Linux, PERMITE a convivência com algumas versões próximas uma das outras, sendo a titulo de exemplo o gcc-7.4 e o gcc-8.3, mas isto só vai ser exequível, se o tal gestor de pacotes, tiver dado instruções, certificando-se de que as duas versões do gcc, sejam instaladas em diferentes paths!?!?
Voltemos novamente ao imaginário …
Agora e por exemplo, eu necessito de realizar testes com o gcc-8.2, sem que isso vá INTERROMPER o sistema?
Ou até mesmo, se eu quiser testar um software usando diferentes versões e combinações de compilador, biblioteca etc.?
E se eu quiser experimentar uma versão beta (mais recente, portanto) de uma aplicação, sem correr qualquer risco para a instalação existente?
Depois, temos mais um problema do suporte a multi-distribuição, sendo que os programadores e os sys admin, NÃO têm forma em como saber, quais as combinações de Kernel, bibliotecas e pacotes que um user se encontra a executar.
Assim, quando um determinado user se encontra a instalar algum software e este reclama pela falta de alguma biblioteca ausente, temos sempre a capacidade para poder sugerir que este tente encontrar os pacotes mais adequados, mas…, o user não realizou os testes na mesma combinação de dependências.
No entanto, podemos sempre construir via sources, mas este pode não se encontrar a utilizar as versões mais apropriadas de bibliotecas e seus compiladores.
(Que dor de cabeça!!!)
Por isso mesmo, o papel dos gestores de pacotes existentes, fazem todos os possíveis para colocar os sistemas estáveis, no entanto, quando os users sentem necessidade de utilizarem software mais recente, concretamente devido a um determinado bug ou até mesmo, porque existe a necessidade de uma funcionalidade extra, acabamos sempre por recorrer aos pacotes denominados de testing ou até mesmo unstable, os quais por regra vêm com uma variedade de dependências as quais também são actualizadas pelos users, colocando INSTABILIDADE noutro tipo de software que dependa desses componentes.
No fundo, e para terminar, direi que os problemas das dependências surgem em torno dos pacotes compartilhados ou até mesmo para bibliotecas, nos quais vários outros pacotes têm dependências, mas onde eles dependem de versões diferentes e incompatíveis dos pacotes compartilhados.
Assim, se o pacote ou biblioteca a ser compartilhada, puder ser apenas instalado e utilizado apenas e só numa única versão, o user pode necessitar de solucionar esse mesmo problema com a obtenção de versões mais novas ou mais antigas dos pacotes dependentes.
A ser verdade este facto, então é verdade também que vai existir quebra de outras dependências e assim “empurrar” o problema para outro conjunto de pacotes.
(Que dor de cabeça!!!)
NOTA: como analogia de tudo isto que acabo de enunciar, estou-me a lembrar do meu Debian Testing+Unstable+Experimental, ali a brilhar numa maquina física!!
Caro Dot, mais uma vez agradeço o seu precioso contributo, mas poderíamos complementar este debate com: Dependências Múltiplas, Cadeias Longas de Dependências, Dependências em Conflito, Dependências de e para os Gestores de Pacotes, etc., etc.
TERMINANDO
Obviamente, que sai completamente fora do âmbito deste artigo escrito pelo Pedro Pinto, no meu entendimento continuar este debate aqui mesmo. Assim, caso queira ou desejem debater este tema, abram um tópico no fórum do Pplware, que quanto a mim é o melhor lugar.