Mostrando postagens com marcador gerenciadores de pacotes. Mostrar todas as postagens
Mostrando postagens com marcador gerenciadores de pacotes. Mostrar todas as postagens

Rodando pacotes .deb no Fedora 35 sem coverte-los com o alien

Rodando pacotes .deb no Fedora 35 sem coverte-los com o alien
Rodando pacotes .deb no Fedora 35 sem coverte-los com o alien

 É comum o conhecimento sobre a execução de pacotes de uma distribuição em outra que não pertença à mesma família através do programa Alien; O Alien é uma ferramenta que converte pacotes de  uma distribuição Linux para outra; porém, alguns erros podem ocorrer nesse processo.

 Mais ou menos em 2018 eu fiz um vídeo intitulado "Rodando pacotes .deb sem instalar" mostrando que é possível fazer esse tipo de tarefa sem a necessidade de convertê-los. O maior problema deste vídeo é que executei um pacotes .deb... no próprio Debian... Digamos que isso acaba não provando que é possível executar pacotes da família Debian em outras famílias de distribuições.

 Pensando nisso eu decidi fazer um novo vídeo porém, desta vez executando o mesmo programa empacotado para o Debian no Fedora seguindo o mesmo processo do vídeo anterior e um pouco mais. Confiram o vídeo:


 É possível também executar programas em pacotes .rpm em outras distribuições que não sejam da família Fedora, mas nesse caso são utilizadas técnicas diferentes. Enquanto os pacotes .deb são na verdade empacotamentos .ar (após serem compactados), os pacotes .rpm por sua vez são empacotamentos cpio.

 Para que possamos melhor interagir com o cpio, mostrarei como gerar seu tipo pacote porém, de certa forma, em ordem inversa uma vez que eu já havia trabalhado no desempacotamento do Google Chrome e aproveitei a mesma situação.

 No exemplo abaixo, na primeira linha marcada podemos ver que listamos os arquivos contidos no pacote google-chrome-stable_current_x86_64.rpm e que foram desempacotados.

 Na segunda linha da imagem acima empacotamos tudo através do comando cpio. Porém, o cpio segue o processo conforme a explicação a seguir e exibido na imagem abaixo. Primeiro listamos todo o conteúdo encanamos a saída (|) do comando ls para a entrada do comando cpio com a opção -o e redirecionamos sua saída padrão (>) para um arquivo. Um pouco trabalhoso, mas é assim que funciona.
 E por fim, na terceira linha da imagem podemos constatar que foi gerado o arquivo backup.cpio.


 Agora sim, podemos trabalhar na explicação do desempacotamento dos pacotes .rpm uma vez que precisamos do cpio para isso. Diferente dos pacotes .deb, os pacotes .rpm precisam de um comando específico para serem desempacotados; nesse caso, o comando rpm2cpio (essa é exatamente a função do rpm2cpio: Extrair arquivo cpio de pacotes rpm).

 De acordo com o manual online do rpm2cpio, existem duas formas de extrair arquivos do pacote rpm. A primeira é exatamente a forma que apresento na imagem abaixo e a segunda encanando a saída do comando cat para a entrada do comando rpm2cpio e depois encanando a saída do comando rpm2cpio para a entrada do comando cpio (cat glint-1.0-1.i386.rpm | rpm2cpio - | cpio -tv).


 Então, tenham sempre em mente que, por se tratarem de binários no padrão ELF LSB (Linux Standard 
Base), os programas do Linux são passíveis de execução na maioria das distribuições; o que acaba impedindo que esses programas sejam executados são as formas como esses binários são empacotados e as informações contidas em seus pacotes.

Será que o dnf do Fedora é tão lento o quanto afirmam?

Será que o dnf do Fedora é tão lento quanto afirmam?
Será que o dnf do Fedora é tão lento quanto afirmam?
 Este é o segundo artigo sobre Fedora que eu escrevo aqui no meu blog. Em uma de minhas lives surgiu uma pergunta a respeito do desempenho do DNF se comparado aos outros gerenciadores de pacotes. Até que eu não vi isso na live, mas uma coisa que percebi entre os usuários de Linux é que já há o mito de ser um gerenciador de pacotes ruim e com péssimo desempenho; e como sempre, todo mito se propaga rapidamente e permanece por longas datas (não importando se desmistifique o assunto)...

 Bom, mas aqui vou eu mais uma vez em uma tentativa frustrante de explicar o óbvio e que parece que não vai adiantar nada. Mas mesmo assim a gente faz.

 No dia 22 de Março de 2020, foi anunciado o desenvolvimento da terceira verso do DNF cujo o seu maior foco é exatamente o desempenho e que de acordo com o próprio artigo do anuncio, esta versão já começa a apresentar bons resultados através de sua biblioteca:

Testes comparativos de desempenho com as versões 0.9.1, 0.11.1 e 0.13.0 da libdnf
 Mas mesmo com os dados já apresentados eu não deixaria de realizar testes também e aqui eu percebo dois problemas entre os usuários sendo que ambos são mais questão psicológicas do que reais, tratam-se de falta de analise e percepção.

 O primeiro afirmam que o desempenho do DNF não é bom se  comparado a outros gerenciadores de pacotes como o APT da família Debian, o portage da família Gentoo, o APK do Alpine Linux e pakman do Arch (como sempre, tudo do Arch é melhor do que de todo mundo...). Até aí não é um problema, o problema é a forma como a ideia acaba sendo mentalizada. Ao invés de "DNF bom e outros gerenciadores de pacotes melhor", a ideia acaba sendo mentalizada como "DNF ruim e outros gerenciadores de pacotes bom". E isso é um problema geral na vida. Ser humano tem um problema psicológico com números.

 Depois começa a desculpa de que foi "pelos testes que fizeram" ou "falam por experiencia própria"... E é uma pior que a outra e é aqui que mora o segundo problema: Não entender como o gerenciador de pacotes funciona.

 Uma coisa que eu percebi (e que em partes achei um pouco incomoda) é quando vou realizar uma busca por um programa sem antes ter realizado um update no DNF. O DNF irá primeiro atualizar a sua base de dados (e caso houver atualizações, irá então concluí-las) para depois realizar a minha busca como pode ser conferido na imagem abaixo.

DNF realizando atualização do sistema antes de realizar a busca solicitada.
DNF realizando atualização do sistema antes de realizar a busca solicitada.
 A principio eu achei isso incomodo mas depois achei até interessante (caso eu não tenha esquecido de verificar pro atualizações, o DNF já fez isso por mim, tudo uma questão de vantagens e desvantagens). Basicamente o APK do Alpine Linux também trabalha desta forma. Após a atualização, todas as demais buscas ficam muito mais rápidas que levam entre 3 a 5 segundos dependendo da sua internet e do seu hardware. Nesse caso falo pela minha internet que é de apenas 5 megabits (que dividindo 5 por 8, corresponde a 625 Kylobytes) e ainda estava assistindo a uma transmissão ao vivo.

DNF realizando a busca solicitada não tendo atualizações.
DNF realizando a busca solicitada não tendo atualizações.
Oscilações na busca do mesmo pacote devido a internet está sendo utilizada.
Oscilações na busca do mesmo pacote devido a internet está sendo utilizada.
 Já o processo de baixar o pacote, suas dependências e instalá-los também não levou tempo. Na imagem abaixo podem ser conferidos o tamanhos dos pacotes, a velocidade com que os pacotes foram baixados, quanto tempo levou para baixar e o tempo total de todo esse processo e de instalação.

Tempo de instalação do Simple screen Recorder no Fedora 31.
Tempo de instalação do Simple screen Recorder no Fedora 31.
 Moral da história é não, não vejo o DNF como possuindo desempenho ruim ao ponto de desenhá-lo como fosse algo que se torna desagradável e impactante da produção. O DNF possui desempenho aceitável? Sim!

 Poderia ser melhor? É CLARO QUE SIM! O Debian mesmo fez isso anos atras melhorando o desempenho do APT e do DPKG da versão 7 para a 8 e do 8 para o 9 como mostrei como mencionei na retrospectiva que fiz . Podemos perceber a diferença de desempenho até mesmo entre o DNF e o próprio Flatpak que também está presente no Fedora (o Flatpak utiliza quase a metade do tempo do DNF).

Benchmark de busca por atualização entre DNF e o Flatpak. Claro que nenhum dos dois precisou resolver nada, mas foi para fins de teste (inclusive, até nada a resolver é um teste valido).
Benchmark de busca por atualização entre DNF e o Flatpak. Claro que nenhum dos dois precisou resolver nada, mas foi para fins de teste (inclusive, até nada a resolver é um teste valido).
 Ou seja, só não da para se manter em uma zona de conforto, mas que o DNF possui desempenho aceitável e não impactante, isso sim. Uma dica é sempre manter o sistema atualizado (nunca deixe as atualizações acumularem) e se quiser aprender mais sobre Flatpak, então aconselho a conferir o site Fast OS e o seu canal.

Lançado novo Minicurso de atributos no Linux

Alpine Linux preparando-se para migrar para o apk-tools versão 3.0


Alpine Linux preparando-se para migrar para o apk-tools versão 3.0
Alpine Linux preparando-se para migrar para o apk-tools versão 3.0
 apk é o gerenciador de pacotes da distribuição Alpine Linux; a distribuição que me fez conhecer, analisar e me apaixonar pela biblioteca C musl. É também a distribuição onde me fez surgir a ideia de muito além do gnu por se tratar de uma distribuição que substituição a maioria das ferramentas gnu de sua base. Eu já relatei sobre essa distribuição na série Os vários sabores de Linux então, antes de darmos continuidade, confira o vídeo aí:


 É comum haver vários gerenciadores de pacotes no mundo Linux. Sem entrar em muitos detalhes e indo para o mais comum, o Debian e derivados possuem o APT, derivados do Fedora possuem o YUM (e adotando o dnf), Suse possui o Zipper, o Gentoo possui o Portage, o pkgtools e o slackpkg, existe também o snap, o flatpak e a lista vai longe... E por que desenvolver mais um gerenciador de pacotes em meio a uma imensidão deles?

 Apesar de já existirem tantos, há motivos reais e específicos para Natanael Copa ter criado o apk. Uma das coisas que me chamou a atenção foi a sua sintax mais simples, o que para o sisadmin é muito interessante. Ao invés de seguir todo um roteiro como no APT de atualizar a base de dados para depois buscar ou instalar algum programa ou atualizar o sistema (e as vezes ainda ter que utilizar o update-rc.d), no apk basta utilizar um único passo como demostrado na imagem abaixo:
Demonstração do APK e do APT
Demonstração do APK e do APT
 Já outros motivos interessantes seria uma base de código limpa que fez com que a distribuição Adélie Linux, mesmo que baseado no Gentoo,  abandonasse o Portage e adotasse o apk. Na imagem abaixo são apresentados mais motivos para o seu desenvolvimento. Acho que é um gerenciador de pacotes que vale a pena ser estudado (e até mesmo adotado. Por que não?)
O que torna o apk-tools rápido
O que torna o apk-tools rápido
 No dia 23 de Janeiro, Ariadne Conill sugeriu como será realizada a migração para a versão 3.0 do apk-tools. A primeira coisa é que o APKv3 deve manter o suporte aos pacotes do APKv2 por um período de tempo (digamos que o óbvio) permitindo uma migração mais segura e com bons testes. Mesmo não tendo muitos detalhes, a linha de raciocínio seria mais ou menos a seguir:
  1. apk-tools 3.0 será lançado nos repositórios de testing.
  2. Usuários que optarem pelo repositório testing, poderão optar pelo apk-tools 3 se desejarem adicionando-o como dependência (apk add apk-tools@testing).
  3. apk-tools 3 utilizar os índices do APKv3, enquanto que o apk-tools utilizará os índices legacy do APKv2.
  4. Se o apk-tools 3 for considerado estável e o suporte a pacotes APKv3 for considerado completo, ele substituirá legacy apk-tools no Alpine 3.12.
  5. Em algum ponto, migrarão para os pacotes APKv3 e encerrarão o suporte aos indices do APKv2 e chamarão esse lançamento de Alpine 4.0.
 Ariadne sugere para as outras distribuições também adotarem a mesma estratégia. Em um eventual problema, simplesmente mantem na  versão 3.13 ao invés de 4.0. Também está em aberto como o apk-tools-static será tratado. Mais detalhes estarão disponíveis quando tiverem um plano específico. Por hora é só o que informaram.

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (19) AMD (14) analise (9) Andriod (14) android (5) artigo (5) aws (1) bc (15) benchmark (3) BSDs (27) btrfs (30) bugs (1) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (24) comp (1) compressores (5) container (6) CPU (19) criptografia (4) crowdfunding (9) cursos (24) daemons (13) Debian (31) desenvolvimento (80) desktop (19) DevOps (3) DevSecOps (3) dic (1) Dica de leitura (86) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (1) diocast (1) dioliunx (3) distribuições Linux (13) Docker (11) DragonflyBSD (20) ead Diolinux (2) edição de vídeo (5) EMMI Linux (4) emuladores (5) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (10) filesystem (75) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (20) Funtoo Linux (13) games (90) gerenciadores de pacotes (3) GOG (3) google (8) gpu (3) hardware (101) hash (1) helenos (3) I.A (1) init system (8) Intel (15) IoT (1) ispconfig (1) jogos (36) kde (1) kernel (134) lançamento (60) leis (1) LFCS (1) licenças (8) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (5) LPI (8) LTS (1) machine learning (1) matemática (4) mesa redonda (27) microsoft (6) microst (1) muito além do GNU (146) não viva de boatos (9) navegadores (3) NetBSD (7) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) open source (82) OpenBSD (5) OpenShift (1) os vários sabores de Linux (39) padrim (2) palestras e eventos (5) partições (6) pentest (8) pipewire (1) processadores (27) professor Augusto Manzano (11) Programação (60) promoção (1) propagandas com Linux (8) Red Hat (21) redes (3) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (1) runlevel (2) segurança digital (19) servidores (1) shell (3) sistema operacional (22) smartphones (3) Software livre e de código aberto (150) sorteio (3) Steam (9) Steam no Linux (7) supercomputadores (4) suse (7) systemd (7) terminal (83) terminal de comandos (11) toca do tux (1) toybox (23) tutorial (6) Tux (3) unboxing (7) UNIX (16) UNIX Toolbox (14) vartroy (1) vga (1) vulnerabilidade (4) wayland (5) whatsapp (1) Windows Subsystem for Linux (2) wine (14) WoT (1) ZFS (13) zsh (2)