Mostrando postagens com marcador Fedora. Mostrar todas as postagens
Mostrando postagens com marcador Fedora. Mostrar todas as postagens

Rocky Linux migrará para Hurd

Rocky Linux Project shifts focus to Rocky GNU/Hurd

Rocky Linux migrará para Hurd

 O projeto Rocky Linux anunciou que pretende migrar para o microkernel GNU Mach que conhecemos pelo nome de suas daemons, o Hurd. 

 Todos nós conhecemos o Rocky Linux e o Alma Linux que como distribuições que surgiram como substitutos ao antigo CentOS que foi descontinuado (mais detalhes sobre o CentOS Stream podem ser conferidos na minha live). Ambas as distribuições passaram a ganhar atenção e até mesmo a serem financiadas por grandes empresas (é, foi necessário acontecer o desastre para depois financiar o que já era para ser financiado...)

State packages for Enterprise Linux

Processo de criação das distribuições da família Fedora

 O Hurd por sua vez é o microkernel do projeto GNU que, além de não ter sido feito pelo próprio projeto, ainda sofre com lentidão em seu desenvolvimento. Mas parece que agora o Hurd está começando a apresentar sinais de poder ser utilizado para que ele inicialmente projeto, "um projeto grande e profissional" pois, para uma distribuição como Rocky Linux que já é utilizada em produção e que está se consolidando anunciar uma migração, é porque coisa boa pode estar vindo por aí. Recentemente eu escrevi que a equipe do Hurd está adotando o framework Rump Kernel, o que pode ter ajudado um pouco nesse processo.

 O projeto anunciou que nos próximos anos estarão trabalhando na migração do RHEL para o Hurd e passará a se chamar Rocy GNU/Hurd. Foi criado até mesmo uma FAQ para ajudá-los entender melhor como será o processo de migração.

 Bom, tudo isso parece até mesmo uma piada de primeiro de Abril, mas é mesmo kkkkkkk

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.

Lançado Hat Enterprise Linux 9 Beta

Latest posts By product By channel What's new in Red Hat Enterprise Linux 9 Beta
Lançado Hat Enterprise Linux 9 Beta

 A Red Hat anunciou no dia 3 de Novembro o lançamento da versão Beta do Red Hat enterprise Linux 9. Além de  trazer melhorias solicitadas pelos clientes, o RHEL 9 é o kernel Linux 5.14 (o mesmo do Fedora 35) com suporte a live patching via web console; foi projetado para trabalhar com de nuvens hibridas; trás suporte integrado a OpenSSL 3 (e senha de root via SSH desabilitado por padrão); autenticação por Smart Card, cgroup2 e o Podman e versões recentes do PodmanGCC 11 e as ultimas versões do LLVM, Rust, GoPython 3.9.

 O RHEL possui suporte as arquiteturas Intel/AMD64 (x86_64), ARM 64-bit (aarch64), IBM Power LE (ppc64le) e IBM Z (s390x).

 Essa versão trás poucas mudanças na usabilidade se comparado com o RHEL 8 (já apresentado aqui no blog) exigindo pouco aprendizado das equipes de administradores de sistema e dev Ops

Lançado Fedora Linux 34 Beta

Lançado Fedora Linux 34 Beta

    No dia 23 de Março foi lançado o Fedora 34 Beta que tem previsão para ser lançada a sua versão oficial no final Abril.

    O Fedora 34 traz o BTRFS com compressão transparente habilitado por padrão gerando maior economia de armazenamento, aumenta a vida de memória flash por reduzir a escrita, melhora o desempenho de  leitura e escrita de arquivos maiores e pode trazer melhorias no futuro já que pretendem continuar utilizando o BTRFS em versões futuras (e assim espero).

Fedora 34 utilizando compressão transparente com o Zstd em sub-volume. Imagem fornecida pelo Renato do canal FastOS

    O PipeWire substitui o PulseAudio para fornecer baixa latência de áudio, possui uma infraestrutura para atender as necessidades tanto de desktios quanto de mixagen profissionais e atender as necessidade decontainers do flatpak.

    O Gnome 40 é o ambiente padrão que traz muitas melhorias de recursos se comparado ao GNOME shell. Já o Fedora KDE Plasma Desktop Spin passa a utilizar o Wayland por padrão (AÔ DELICIA) e traz também a primeira versão para a arquitetura aarch64. O Fedora 34 Também traz a primeira versão com a interface i3:

Fedora 34 Spin com i3

    E por ultimo traz habilitado por padrão systemd-oomd para os units do systemd. Todas as informações podem ser lidas no site Fedora Magazine e  no próprio site do Fedora.
Agradeço ao Renato do canal FastOS pela imagem do Fedora 34 com compressão transparente com o Zstd.

Descobertas vulnerabilidades na parte de rede do Linux


    As falhas foram descobertas por Alexander Popov da empresa sediada em Londres Positive Technologies. Alexander Popov é um engenheiro de software que de 2012 á 2016 teve 14 patches aceitos  na mainline do kernel Linux. Este ano Alexander descobriu e corrigiu cinco brechas na implementação do virtual socket do kernel Linux (que apareceram quando o virtual socket multi-transport support foi adicionado) que permitiriam ser utilizadas para escalar acesso como root e derrubar servidores com um ataque DoS (Denial of Service).


 Apesar que Alexander descobriu as vulnerabilidades no Fedora Server 33, elas existem em qualquer distribuição que estiver utilizando o kernel Linux 5.5 em diante. Greg Kroah-Hartman aceitou os patches de ALexander a partir do kernel 5.10.13 no dia 3 de Fevereiro (que já foram incorporados em distribuições como Fedora 33, Red Hat Enterprise Linux (RHEL) 8, Debian, Ubuntu e SUSE).

Lançado Fedora 33 com o sistema de arquivos Btrfs

Lançado Fedora 33 com o sistema de arquivos Btrfs

 Hoje é um dia muito importante, o dia tão esperado do lançamento do Fedora 33 pois trata-se de um lançamento histórico onde o Fedora migrou do sistema de arquivos Ext4 para o Btrfs. Muitos novos recursos surgiram no Btrfs para atender a necessidade do Fedora (o que influenciará também no Red Hat Enterprise linux e no CentOS caso ambos também o adotem). Então acompanhe a gente hoje às 20:30 pois tenho algumas surpresas para vocês lá no canal ;)


Btrfs poderá receber novo recurso para ser adotado no Fedora 33

Btrfs poderá receber novo recurso para ser adotado no Fedora 33
Btrfs poderá receber novo recurso para ser adotado no Fedora 33
 Durante a conversa sobre a possível migração do Fedora 33 para o Btrfs (e que pode ser lido clicando aqui), foi mencionado que o Btrfs é particularmente vulnerável a corrupção de metadados (caso uma das raízes globais centrais (em inglês core global roots) venha a corromper, o sistema de arquivos é desmontados e o fsck não consegue fazer nada sem algumas opções especiais.

 Foi aí que sugeriram um adicionar suporte a opção rescue=skipbg ao Btrfs (automaticamente, ao comando mount também). Porém essa opção é muito fraca por só permitir operar sem um extent root e outras opções foram sugeridas como 
mount -o rescue=skipbg,rescue=nocsum,rescue=nofreespacetree,rescue=blah
  Apesar de já estarem trabalhando no patch para o novo recurso, a equipe anda está analisando quais são as melhores e mais vantajosas opções para os usuário. Testes estão sendo realizados com vários dados ao corromper as csum tree e o debate ainda está sendo longo.

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.
NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

Lançado Fedora 32

Lançado Fedora 32
Lançado Fedora 32
 Logo hoje (dia 28 de Abril de 2020) que disponibilizei o artigo Utilizando o Zsh no Fedora foi anunciado o lançamento do Fedora 32. Como descrito por Matthew Miller (lider do projeto Fedora) que sempre obtemos a experiencia com a ultima versão software open source para todos os ambiente que o Fedora é oferecido (workstatin, spins servidores, IoT e etc...) e mantendo sempre a qualidade e estabilidade dos pacotes.

Esta nova versão está disponível para as arquiteturas x86-64 (AMD64) e ARM (AArch-64) não sendo mais disponibilizado para x86 de 32 bits na versão Workstation e IoT, mas ainda sendo mantida para a versão servidores. Há informações de suporte as arquiteturas Power e S390x, mas não as encontrei.

 Dentre as novidades estão GNOME 3.36, o GCC 10, Ruby 2.7, e Python 3.8 (um legacy do Python 27 é mantido). Caso esteja utilizando a versão 31 (assim como eu) e quer atualizar para a versão 32, Adam Šamalík disponibilizou hoje também um artigo como fazer isso, basta clicar aqui. e se quiser saber mais detalhes, o Renato do FastOS e Oficina do Tux fez um vídeo hoje testando a nova versão. Confiram aí:

Utilizando o zsh no Fedora

Utilizando o zsh no Fedora
Utilizando o zsh no Fedora
 Terceira dica sobre o Fedora no meu blog. A primeira foi sobre o VirtualBox no Fedora que, relembrando, foi o motivo que levou a muitos novos usuários com uma atitude muito imatura serem  maltados. Ok, e esse é o segundo artigo que pretendo dar algumas dicas sobre o Zsh no Fedora. O segundo trata-se de uma analise sobre o desempenho do DNF. E agora, vamos ao Zsh no Fedora.

 Em meu curso explico como utilizar outros terminais além do Bash como o Zsh e Fish (não quero que as pessoas fiquem limitadas; isso é muito além do GNU. Não se trata de eliminar o uso das ferramentas do projeto GNU, trata-se de expandir duas opções e possibilidades). Apesar disso, foquei muito no Zsh já que é o terminal que está ganhando cada vez mais destaque (até mesmo a Apple passou a adotá-lo no lugar do Bash no MacOSX já quqe agora o Bash está sob GPLv3).


 Bom, aconselho a instalar o zsh direto dos repositórios do Fedora para garantir atualizações de forma mais pratica (sudo dnf install zsh ou #dnf install zsh). Concluída a instalação, podemos conferir que o zsh faz parte da lista de terminais que está disponível na distribuição.

lista de terminais disponíveis no sistema operacional e que podem ser conferidos dentro de /etc/shells
lista de terminais disponíveis no sistema operacional e que podem ser conferidos dentro de /etc/shells
Ok, primeira observação. OS arquivos de configuração do Bash ficam dentro de /etc/skel enquanto que os arquivos do Zsh vão para seu próprio diretório em /etc/zsh. Já no Fedora, esses arquivos ficam separados em /etc tendo o zshrc; porem dentro de /etc/skel encontramos o arquivo .zshrc junto com os arquivos do Bash. Em que isso interfere? Em nada, mas fica a dica caso queira localizar os arquivos

Arquivos de configuração do Zsh no Fedora.
Arquivos de configuração do Zsh no Fedora.
 E agora chegamos no ponto para utilizar o Zsh, que na verdade há algumas. A primeira (e é a que quero tratar aqui) é digitando o comando zsh. Simples assim e essa é uma regra que vale para qualquer terminal que estiver disponível no sistema operacional. O problema é que no Debian aparece uma mensagem perguntando se quer que populo o seu perfil com os arquivos de configuração do Zsh; o que aceitando, fica tudo pronto para uso. Já no Fedora aparece a mesma mensagem, mas para procedimentos a serem realizados antes de estar preparado para uso. Então eu elaborei um vídeo explicando como configurá-lo ao invés de explicar tudo por escrito (já que ficaria longo demais ;)

curso-linux-da-migração-a-administração-do-sistema-operacional
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.

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

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)