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.
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
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.
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 ;)
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).
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:
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.
Hoje falo em defesa dos novos usuários de Fedora que com boa vontade querem aprender a usar a distribuição; pois no final de semana passada aconteceu algo que achei ridículo por parte de um grupo que se denomina os bons de Fedora Linux. O que me irrita é a hipocrisia por parte do grupo em que a única cordialidade que vi por lá é ao receber novos membros do grupo com um "seja bem vindo fulano". Depois disso criticam novos usuários e ainda os apelidando de geração Nutella (acho esse termo um tão quanto pobre) quando perguntam como instalar Virtual box ou Java ou outros programas que eles acabaram criando uma listinha negra que envolvem:
Virtualbox
Warsaw
MySQL
Java
Flash
São tão espertos que nem sabem que a licença padrão do Virtual Box está sob licença GPL (quer dizer, estão lutando contra si mesmo) e envolve outras parte sob licença como a CDDL (que deriva da MPL e que por sua vez deriva da GPL), Java é parte GPL e parte Java Community process, MySQL éparte GPL e parte comercial. Deveriam estudar mais ao invés ficarem formulando uma listinha negra onde definem quais programas são uma heresia e quem os usam são hereges. E mesmo software pago, ou simplesmente proprietário ou não aberto, é feito para ser utilizado e não adorado.
Este artigo não tem nada de novidade; eu já devia ter feito isso mais ou menos quando fiz o vídeo defendendo os usuários novatos do Fedora que eram (ou ainda são) hostilizados por simplesmente perguntar como instalar VirtualBox na distribuição...
Há outros grupos que já ensinaram como fazer isso (sugeri publicar este artigo em um grupo, mas como eles já tinham publicado algo, resolvi publicar aqui no blog), mas resolvi também explicar por dois motivos.
Ocorreu uma situação na empresas em que nesse período de quarentena, trabalhando home office, fui obrigado a utilizar o Windows para acessar certo sistema do cliente. Então, uma das soluções foi rodar Windows em uma máquina virtual. E foi aí que surgiu a ideia de aproveitar a situação para explicar aos novos usuários como instalar o VirtualBox no Fedora; caso eles queiram, vão poder consultar aqui.
O segundo é que como há espaço para todo mundo, porque não?
O procedimento que realizei e que será utilizado aqui será todo em linha de comandos por questão de habito, mas se você souber outra forma de instralar, lhe encorajo e apoio a compartilhar conhecimento.
Bom, o Virtualbox não está nos repositórios do Fedora nem no rpmfusion non-free e nem em flatpak (ou ao menos não encontrei. Vai saber), sendo disponibilizado pela própria Oracle em seu site oficial. Para Linux, vemos versão para Oracle Linux, Red Hat Enterprise Linux e CentOS (versões 6, 7 e 8); Ubuntu (14.04, 14.10, 15.04, 16.04, 18.04, 18.10, 19.04 e 19.10); Debian (8 ao 10), OpenSuse (13.2, Leap 42 e 15.10) e Fedora (do 26 ao 31). Seria interessante se houvesse versão flatpak ou snap; como não há, Eu baixei de acordo com a versão do Fedora que estão utilizando, que no caso é a 31.
Versões do VirtualBox para as principais distribuições Linux no site oficial da Oracle.
Após baixar e executar o comando rpm -ivh, o virtualbox foi instalado com sucesso (pena eu não ter printado as telas para escrever este artigo, isso não veio a mente na hora) não apresentou os mesmos erros que já me ocorreram no Debian e também não foi necessário adicionar o usuário a nenhum grupo (como ocorreu no Debian 9). Porém ainda assim alguns outros pequenos erros ocorreram, mas nada do que a simples leitura das informações exibidas resolva.
O primeiro problema que o VirtualBox reportou foi que possívelmente faltavam os módulos do kernel ou que o AMD_VIRT foi desativado pelo BIOS. Ativei o suporte a virtualização no BIOS/UEFI e o VirtualBox já estava abrindo, porém ainda faltavam realmente os módulos do kernel e o VirtualBox reportou para executar (como administrador) o comando /sbin/vboxconfig.
Suporte a AMD-V no processador Ryzen
OK, executado o comando vboxconfig, o comando reportou que faltavam dependências como make e kernel-devel. Na verdade o comando vboxconfig lhe exibe uma lista do que instalar; se já houver, tudo bem, não vai dar nada de errado. Então eu digitei o comando:
#dnf install gcc make kernel-devel kernel-devel-debug-internal-5.5.13-200.fc31.x86_64
Após instalação do que o VirtualBox solicitou, novamente executei o comando /sbin/vboxconfig que configurou tudo corretamente e pude trabalhar com o VirtualBox.
Rodando o comando /sbin/vboxconfig para configurar os módulos do VirtualBox
ReactOS rodando dentro do VirtualBox do Fedora para acessar o sistema remotamente. Só ignorem o meu gato, ele sempre quer dormir na frente do monitor.
Um problema comum que pode ocorrer é que depois de uma atualização do Fedora (sendo uma delas o kernel), o VirtualBox parar de funcionar e você receberá esta mensagem ao executar o VirtualBox.
Nesse caso,execute novamente o comando /sbin/vboxconfig que o VirtualBox voltará ao normal (ou pode ser que não). Na segunda situação em que nem o comando /sbin/vboxconfig funcionará, esta mensagem no terminal será exibida:
Já nesse caso você deve baixar uma nova versão do VirtualBox no site da oracle. Antes de instalar a nova versão, a anterior deve ser desinstalada como na imagem abaixo:
Removendo o VirtualBox
Feito isso, basta repetir os mesmo processos (instalar o VirtualBox e executar o comando /sbin/vboxconfig) e pronto, sua máquina virtual está funcionando novamente.
VirtualBox funcionando novamente.
Então é isso galera; a intenção (mesmo que nada disso é novidade) é ajudar aos que pretendem utilizar o VirtualBox no Fedora. Bom estudo e trabalha a todos e tudo de bom.
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í:
Pois é, o anuncio foi feito recentemente no próprio projeto e já há uma longa discussão sobre o assunto.
O vídeo da semana que vem já está pronto e trás uma noticia muito interessante, agora o Fedora também passará a adotar o LLVM/Clang ao invés do GCC. Mais uma das principais distribuição Linux que migra para esse poderoso compilador:
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.
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.
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.
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!
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.
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.
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 ;)
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.
Esses tempos resolvi utilizar o Windows 8.1 Pro na empresa que estou trabalhando e resolvi compartilhar essa experiência com vocês*...
Cara de Ubuntu do caramba (ou de Gnome; só que invertido)
Parece que a Microsoft tem a ideia de que os seus usuários são desbravadores, porque a cada versão é uma surpresa. Do XP para o Vista foi uma guerra civil na sua curva de aprendizado; o 7 tentou apagar esta impressão, agora... no 8 e 8.1 .... Nass.... As mudanças são radicais.
Eu resolvi manter minha máquina com Windows para eu atender ao pessoal em suas estações, assim poderia me adaptar e não precisaria ficar perdendo tempo em ficar procurando as coisas na máquina do pessoal ao atender. Temos servidores Linux e para algumas aplicações temos um servidor Windows server (não me perguntem o por que, cheguei na empresa e já funcionava desta forma).
Bom, já não sou muito bom com as GUIs (por essa razão que uso o MATE, por estar acostumado com o padrão do antigo GNOME). Até me adaptei ao novo Gnome no Wheesy, mas ainda prefiro o Mate. Bom, por fim, eu poderia pedir para utilizar o Linux, meus chefes não se importariam; mas como há estações Windows aqui, prefiro tentar me adaptar para atender ao pessoal. agora, imagina a cena:
Eu... acostumado com terminal... de repente me deparo com o Windows 8.1. Pow, quando clico no iniciar, eu me sinto como se estivesse em uma festa rave, tomando energético e absolut**. Abre um painel muito do doido que vira um festival e tudo começa a girar (só faltava a musica e estava tudo certo); não sei para aonde ir ou o que fazer (nem aonde estou ou como sair dalí). Me senti totalmente dopado. A Microsoft retornou o botão iniciar, mas basicamente deu tudo na mesma, como se não tivesse ali.
Bom, por acidente, eu passei o cursor do mouse no canto superior direito da tela e aparece isso:
Interface Unity do Ubuntu
Interface Gnome no Fedora
Interface Gnome no Fedora
Interface do Windows 8.1
Na hora eu lembrei da interface Unity do Ubuntu e em seguida lembrei do Gnome. As pessoas dizem que muitos recursos do Windows 10 foram copiados do Linux, mas isso já é visto bem antes disso. Esse mesmo é uma cópia bem óbvia do Gnome com cara de windowsphone tudo junto, só que a Microsoft sempre inverte aonde os recursos copiados ficam localizados. Sempre foi assim, até mesmo os recursos copiados do Mac OS foram simplesmente invertidos em suas localizações (os botões de maximizar, restaurar e fechar quem o digam).
Já me falaram que a Microsoft é padronizada enquanto que o Linux não. Difícil, na verdade, é ver isso no Windows. Se com um único sistema, nunca há um padrão, imagina se tivesse distribuições Windows... noss... a guerra estaria feita.
*A intenção aqui não é difamar o Windows, e sim relatar a experiência que até então não tinha vivido e nem conhecia. Mas Microsoft, fica aqui uma critica para bem dos seus usuários, siga uma linha de padronização.
Apesar da minha paixão pelo KDE, o Gnome (assim como o Debian) é a interface Gráfica mais utilizada no Linux; porém não de forma pura, mas unindo seus derivados como do PopOS, do EndlessOS, o antigo Unity do Ubuntu, a versão do Deepin Linux e muito mais. Eu gostava da antiga versão do Gnome que utilizávamos em versão como o Fedora 6, Fedora 9 e assim por diante. Quando o Debian migrou para o Gnome 3 eu acabei perdendo interesse devido o Gnome ter mudado radicalmente. Ainda assim há coisas que eu gosto no Gnome como abraçar tecnologias de forma mais rápida como o Wayland, flatpak, capabilities e o systemd.
Porém algo que me chamou atenção (e até me surpreendeu) foi que no dia 14 de abril o projeto Gnome postou eu seu Twitter a seguinte frase:
Vamos também esclarecer isso aqui. GNOME NÃO é um projeto GNU.
Vamos também esclarecer isso aqui. GNOME NÃO é um projeto GNU.
Eu confesso que fiquei surpreso pois sempre acreditei que fosse baseado no argumento de que o Gnome é construído sobre o GTK (como se o fato de utilizar uma ferramenta tornasse um projeto propriedade do outro...). Mas até aí tudo bem, a questão é que entre apoiadores e criticos, foi uma discussão gigantesca que rendeu assunto. Bom, treta é o que não faltou (já que os defensores ferrenhos da "liberdade" acham que qualquer um que não apoia as suas "ideologias" são radicais e subversivos e não adianta argumentar, eles sempre vão querer arrumar defeitos para argumentos. Velho argumento: Acuse os adversários do que você faz e chame-os do que você é).
Um comentário interessante foi do Gerente de Engenharia da Red Hat Alberto Ruiz e que também já trabalhou em empresas como Canonical, Codethink, Sun Microsystems que, quando mencionado que o Gnome está listado no projeto GNU e que deveriam pedir para removê-los da lista, Alberto afirmou que já haviam pedido por muitas vezes e que o projeto GNU se recura a remover. (essa eu devo ao Renato do canal FastOS até pela paciência dele de filtrar tanto as coisas).
Outro comentário que gostaria de mencionar foi esse aqui questionando se a história sobre o termo gnu/Linux precisa ser reescrita.
A questão é que a história ela nunca foi realmente escrita, ela foi unicamente contada por apenas um lado (pelo GNU para se promover).
Por conta de dizer a verdade e da minha série intitulada Muito além do GNU, até hoje há muitos afirmando que "eu odeio GNU"... Eu vou voltar a repetir o que eu já disse. O nome da série é MUITO ALÉM DO GNU e não eu odeio GNU; o que eu mostro é como o mundo open source é muito mais amplo do que o projeto GNU tem a oferecer (e muitas vezes melhor). O problema dos que afirmam isso é que eles só enxergam o que eles querem, se tornaram escravos disso (fato estranho para os que defendem a "liberdade"). Agora, se me acham radical por conta de Muito além do GNU, então fiquem com o comentário abaixo e divirtam-se (ou chorem, que é o que sabem fazer de melhor).
Estou percebendo que em breve vamos ver o mesmo cenário se repetir com GTK, o Gimp, o wget, o patch, o ncurses e muitos outros já que o projeto GNU gosta de brincar de senhor feudal no mundo do software ("liberdade"...).
