Visite também: Currículo ·  Efetividade BR-Mac

O que é LinuxDownload LinuxApostila LinuxEnviar notícia


Um “Binário Universal” para o Linux: FatELF

Enviado por Thomaz dos Reis (thor27Θgmail·com):

“O programador, responsável pela versão de Linux de diversos jogos como Unreal Tournament, America’s Army, Prey e mantenedor de diversos projetos livres, acaba de lançar o FatELF: Um binário executável que permite unir diversos outros binários de diversas plataformas diferentes em apenas um, da mesma forma que o “binário universal” funciona no MacOS X.” [referência: icculus.org]

• Publicado por Augusto Campos em 2009-10-21

Comentários dos leitores

Os comentários são responsabilidade de seus autores, e não são analisados ou aprovados pelo BR-Linux. Leia os Termos de uso do BR-Linux.

    Orlando Xavier (usuário não registrado) em 21/10/2009 às 1:24 pm

    Muito bom. :-)

    Diogo (usuário não registrado) em 21/10/2009 às 1:38 pm

    Ta aí uma coisa boa! Mas no fundo não funcionaria da mesma forma que os aqruivos .run que tem por aí? Ou não?

    Paulo Cesar (usuário não registrado) em 21/10/2009 às 1:46 pm

    @Diogo

    Não.

    Marcelo Nascimento (usuário não registrado) em 21/10/2009 às 2:10 pm

    O espaço em disco ocupado em servidores diminui muito, o usuário não tem o trabalho de escolher o que baixar. Mas uma instalação ficar cheia de executáveis “inchados” com os das outras arquiteturas? Não é isso que vai acontecer?

    Diogo (usuário não registrado) em 21/10/2009 às 2:15 pm

    @Paulo Cesar
    Obrigado!

    Mas fico imaginando a possibilidade de distribuir programas nesses binários em vez de arquivos empacotados para cada distribuição. Não juntaria “lixo” no sistema? Sei lá, eles trariam bibliotecas necessárias para rodar o programa e ficaria redundante no sistema. Ou então to entendendo de forma errada a utilidade disso.

    gustgr (usuário não registrado) em 21/10/2009 às 2:18 pm

    A proposta eh um binario independente de plataforma e nao um pacote que funciona em qualquer distribuicao.

    Suhanko (usuário não registrado) em 21/10/2009 às 2:41 pm

    Enfim, chegaram os virus no linux

    supporter (usuário não registrado) em 21/10/2009 às 2:44 pm

    Eu fico surpreendido de quanta gente tem que só conhece x86…

    Igor Cavalcante (usuário não registrado) em 21/10/2009 às 2:45 pm

    Isso quer dizer que … um binário 32 bits rodaria em uma máquina 64 bits tranquilamente?

    miranda (usuário não registrado) em 21/10/2009 às 2:49 pm

    “Enfim, chegaram os virus no linux”

    Pensei a mesma coisa…

    “A proposta eh um binario independente de plataforma e nao um pacote que funciona em qualquer distribuição.”

    Desculpa a ignorância mas…um pacote não é um binário? Um binário do OpenSUSE não é um pacote do OpenSUSE?

    Conan (usuário não registrado) em 21/10/2009 às 2:58 pm

    @supporter,

    Concordo, tem muita gente aqui que acha que conheçe tudo, mas no fundo, não sabem nada. Será que algum dia vão descobrir que o mundo não é feito só de intel x86?

    João (usuário não registrado) em 21/10/2009 às 3:09 pm

    Um formato binário universal desses pode eliminar a necessidade de pacotes para diferentes arquiteturas, o que é uma coisa muito boa.

    Diogo (usuário não registrado) em 21/10/2009 às 3:16 pm

    Então significa que podemos ter exatamente o mesmo binário rodando por exemplo no N900 e no PC. O que é muito bom!

    lordtux (usuário não registrado) em 21/10/2009 às 3:19 pm

    O que deveriam mesmo é padronizar um unico tipo de pacote para todas as distribuições, facilitaria e muito a vida de muita gente, o que ajudaria também a reduzir muito o espaço nos servidores.

    Sei que não é tão fácil, mas é possível se chegar em um consenso, se as grandes distros passassem a adotar isso, concerteza todas as outras fariam a mesma coisa.

    ThOR27 (usuário não registrado) em 21/10/2009 às 3:21 pm

    Bem, pelo que eu li no site e nas docs, não vai aumentar muito o tamanho do programa no total, e vai facilitar a distribuição de aplicação entre plataformas diferentes, por exemplo você faria um 1 executável e ele iria rodar tranquilamente em x86, amd64, sparc etc etc. E pelo que vi também funcionaria para módulos entre outras tecnologias.

    @diogo

    Isso não tem NADA haver com empacotamento. Isso é com o executável e aquiteturas de plataformas, os empacotamentos continuariam a existir do mesmo jeito.

    bem, no mac universal é algo que funciona em power pc e intel, certo? O Linux suporta muito mais plataformas, mas são em situações diferentes. A não ser que os netbooks com processador ARM façam sucesso. Caso contrário, não há a necessidade de se rodar o KDE num celular ou um software de celular num PC.

    A idéia é interessante em situações específicas, mas para uso geral é bom manter as coisas como estão.

    Ah sim, e entre as distribuições, se houver uma compatibilidade entre a glibc as coisas normalmente funcionam bem (e se vier tudo linkado estaticamente então…)

    Ah, e outra coisa: é bom o cara mudar de nome o negócio senão a Microsoft vai processá-lo por usar indevidamente sua propriedade intelectual (FAT?) hauahauhaua

    twewehgasaza (usuário não registrado) em 21/10/2009 às 3:42 pm

    OBAAAAA!!!
    vou poder fazer meus virus pra windows sem ter que me preocupar em manter uma instalação de windows so pra isso… :D :D :D

    Ainda quero ler mais sobre o assunto mas até agora não gostei da idéia. Pelo que eu entendi é simplesmente um arquivo com algum cabeçalho seguido de um executável para cada tipo de plataforma suportada dotos comprimidos no formato zip e o sistema escolhe o mais adequado, descompacta na RAM e executa. Para funcionar de verdade, seu programa tem que estar compilado estaticamente com tudo que ele possa precisar. Se fossem só duas ou três plataformas tudo bem, mas são muitas plataformas suportadas pelo Linux e alem disso existem muitas versões de bibliotecas da base do sistema como a zlib e a libc rodando por ai.
    Se fossem poucas plataformas e plataformas em que você sabe que versão das libs básicas esta rodando até que é uma idéia legal, mas para o Linux, vai ser um executável enorme que leva um tampão para ser compilado. Bom vou ler mais, se eu entendi errado me corrijam. De qualquer forma esse assunto me interessa e muito.

    You can remove all the confusing text from your website about “which installer is right for me?”

    Quantas pessoas que usam Linux e baixam e instalam programas ficam confusas com isso?

    Fábio Prudente (usuário não registrado) em 21/10/2009 às 4:34 pm

    Gente, eu tb concordo com todas as críticas apresentadas, mas vejo uma situação em que essa solução pode ajudar bastante.

    Em vez de pensar em binários para diversas arquiteturas (nesse caso, o melhor mesmo é baixar direto o binário para a sua arquitetura), pense em empacotar em um único arquivo os binários para diversas ABIs (mesma arquitetura, mesma distro – apenas versões diferentes de ABI).

    Isso seria uma grande ajuda para o inferno das dependências, nos pacotes atuais.

    João (usuário não registrado) em 21/10/2009 às 5:00 pm

    Eu li um pouco sobre o formato e entendi que é muito mais simples do que parece. É só um bocado de executáveis juntamente com um header indicando onde está cada um e indicando a arquitetura, ordem de bytes, etc. Considerando isso:

    1) Não é exatamente o mesmo binário. São binários diferentes dentro de um mesmo arquivo. O carregador do FATElf é que teria o trabalho de verificar se dentro do FATElf há um binário que a plataforma em questão pode usar.
    2) Não há nenhum tipo de compressão. O autor quis dizer que, como os executáveis em si não são alterados, você ainda pode fazer coisas como criar arquivos ZIP com extração automática, etc. Ou seja, você pode criar vários arquivos SFX para várias plataformas diferentes. Isso é uma resposta à dúvida: “Po, mas isso não vai quebrar meu arquivo SFX?”.
    2) De onde tiraram a idéia de que isso pode significar algum tipo de vírus? Que viagem na maionese! É só um monte de executáveis juntos, pessoal. Só isso. Não tem nada mágico. O que vai ser executado é o que você incluir no FatELF.
    3) Não será necessário compilação estática, etc. É só um formato que engloba binários diversos. Só isso. Você ainda pode depender das libs do sistema.
    4) Será que o tamanho dos binários é o maior dos problemas? Eu não acredito. Lembre-se: isso não significa que todos os binários incluirão todas as libs automaticamente. As libs continuarão sendo necessárias para cada plataforma. Não vai ser um executável enorme que leva um tempão para ser compilado porque você ainda precisará fazer uma compilação para cada configuração/plataforma/etc. O tempo de compilação para cada uma não muda.

    João (usuário não registrado) em 21/10/2009 às 5:03 pm

    Correção: melhor ainda, o FATElf pode ser usado para libs também. É claro que você não vai incluir binários para todas as plataformas do mundo, mas pense em um caso muito interessante, que é a possibilidade de ter binários e libs para 32 e 64 juntas.

    É, realmente não é a solução que eu imaginava, fui com muita sede ao pote.
    Claro, você não precisa fazer uma compilação estática, mas se as libs que você precisa ela não estiver na maquina alvo ou se a versão for diferente e não houver uma compatibilidade binária, seu programa não vai funcionar. Se for só para duas arquiteturas até é interessante mas para todas as suportadas fica inviável. Leva um tempão para compilar se for da forma como eu havia imaginado, compilar uma vez para cada arquitetura e inluir no fatelf.
    Para duas ou três arquiteturas e em um sistema que já é naturalmente grande como um jogo realmente vale a pena. Infelizmente para o que eu preciso não serve.

    Na realidade já existe há muito tempo shell scripts que contêm na parte final binários ELF e isso é inclusive um recurso muito usado por malwares

    http://www.net-security.org/malware_news.php?id=55

    A novidade me parece ser a inclusão de binários para mais de uma arquitetura, a deteção automática da plataforma e instalação do binário adequado.

    Logicamente isso facilita bastante o trabalho dos programadores de software proprietário e do pessoal “do mal” que faz os malwares. Para o usuário leigo pode até ser uma coisa legal mas não vai ser a panacéia.

    Acho que para os softwares livres mais tradicionais que constam nos repositórios das distribuições isso não acrescenta nada e nem vai fazer com que as distribuições abandonem os apt-get, urpmi, yum, etc. Trocar pacotes binários pequenos e instaláveis e atualizáveis por comandos simples ou utilitários gráficos por um binário enorme, cheio de coisas inúteis, não é prático nem racional.

    bonnot (usuário não registrado) em 21/10/2009 às 6:20 pm

    “Manoel Pinho”++

    Felipe Lessa (usuário não registrado) em 21/10/2009 às 6:50 pm

    Por favor, por favor, por favor, publiquem agora este post aqui:
    http://www.mega-nerd.com/erikd/Blog/CodeHacking/osx_ub.html

    ejedelmal (usuário não registrado) em 21/10/2009 às 7:40 pm

    LLVM now!!!

    Curioso (usuário não registrado) em 21/10/2009 às 7:42 pm

    Por isso o Linux não pega nos Desktops, arquivos inchados? Espaço não é problema a muito tempo, nem em disco nem em memória.

    Na minha opinião, fora os arquivos do sistema, os programas tinham que ser completos, ou seja, com todas as suas dependências juntas no mesmo arquivo, isso garantiria que o mesmo rodaria em qualquer distribuição, sem problemas de dependências.

    Mas para que facilitar?

    Os usuários são inteligentes o suficiente, se caso a sua distribuição não tenha o programa que ele necessita ele baixa os fontes, resolve as dependências e compila.

    Sei que é meio off, mas este é o principal motivo que prende o Linux nos servidores e em usuários avançados de informática.

    Os advogados, dentistas, engenheiros, médicos… as pessoas em geral querem simplesmente usar, como usam os carros, o mp3, o celular,… sem se importar em saber como funciona.

    @Curioso,

    O problema é de mentalidade. Uma máquina windows ou Mac típica normalmente não chega a ter mais de 50 programas. O registro do windows quase implode quando você instala muitos aplicativos. Windows e Mac vocẽ parte basicamente da instalação do sistema operacional com poucos aplicativos instalados automaticamente na instalação e depois você vai instalando um a um os aplicativos. Numa instalação de linux você pode selecionar os pacotes que quer ainda na instalação e no final tem um sistema completo, inclusive com aplicativos.

    Uma máquina linux, mesmo desktop, pode ter mais de 1000 pacotes. Só a minha tem 2503 pacotes até o momento. Imagine a gordura em 2500 binários FatELF.

    Eu administro um forum sobre linux e uma pergunta típica de usuário novato é como instalar programas baixados de sites como superdownloads. Preciso explicar que antes de sair tentando instalar programas de terceiros na mão a pessoa deve aprender a usar os repositórios da distribuição. É MAIS FÁCIL instalar programas de repositórios do que baixar, clicar em arquivos .exe ou .msi e reponder um monte de perguntas dos diferentes instaladores para cada programa.

    Resumindo, minha opinião é a de que binários universais não substituirão os pacotes das distribuições linux. serão apenas mais uma das muitas formas que existem para instalação de programas de terceiros no linux, assim como outras iniciativas como o autopackage

    http://www.guiadohardware.net/tutoriais/dominando-autopackage/

    @ejedelmal

    Quando eu li o titulo o que veio a minha mente tinha feito algo parecido com o LLVM. Pena que eu me enganei.

    @Curioso
    Não tem como atingir esse objetivo dos programas serem autocontidos com tudo o que é necessário para rodar o programa contido nele mesmo. Sempre haveria dependências ou diferenças entre plataformas. Mesmo que você compile tudo estaticamente incluindo a libc e tudo mais você termina com um executável grande que mesmo assim ainda vai depender de se tudo aquilo que você compilou estaticamente funciona sob o kernel da plataforma da maquina alvo. E essa não é uma limitação do Linux isso acontece em todas as plataformas. Essa é a causa do DLL Hell no Windows por exemplo.
    Alem de ser tecnicamente impossível ter um programa 100% autocondido devido a dependência do kernel e as diferenças entre as plataformas. Mesmo assim se isso fosse possível não seria bom, já imaginou cada programa que você estiver usando carregando sua copia de tudo na memória? Basta um ps -aux para ver que tem muita coisa rodando ai.

    dasj (usuário não registrado) em 22/10/2009 às 1:10 am

    agora que a rede dos pacotes ta estabilizada… fica dificil substituir mesmo.
    Concordo que é BEM mais facil usar um sistema de pacotes (PKG) do que ir de site em site baixando executavel.

    Mas, por outro lado, pensar na ECONOMIA de TRABALHO que seria gerada so por evitar a duplicidade de trabalho nas milhares de reepacotações.. é tentador

    pimentel (usuário não registrado) em 22/10/2009 às 2:58 am

    Curioso, A seguinte frase dita por outros e repetida por você não é nada original:

    “Por isso o Linux não pega nos Desktops”,

    Não são as características do linux que o faz restrito no uso dos desktops e sim a pirataria do Winmdows,que é tão grande que toma o espaço que seria do linux se a pirataria do Windows não existisse,mas isso é outro assunto que não cabe discutir aqui.

    Curioso (usuário não registrado) em 22/10/2009 às 8:55 am

    @Manoel Pinho
    Este é um problema que vejo, temos que depender da distribuição, ou da boa vontade do desenvolvedor de disponibilizar o programa para cada distribuição. Fora o problema de suporte, não consigo me imaginar dando suporte a um programa para cada distribuição, aonde cada uma adota uma maneira de inicialização, de configuração,… E a cada versão nova da própria distribuição, em muitos casos temos que refazer o pacote para a mesma. Não tem desenvolvedor que aguente.

    @Cesar
    Não vejo problema em ter vários aplicativos rodando com tudo estaticamente, usuários comuns não utilizam muitos programas juntos. Repito memória não é mas problema para um desktop, hoje máquinas com 2mb a 4mb estão se tornando padrão para que possam rodar o Seven. Eu acho que o custo benefício seria muito bom para o usuário.

    @Pimentel
    Claro que a pirataria do Windows enfraquece o Linux nos Desktops. Mas na minha opinião a dificuldade de instalação e a falta de aplicativos de “terceiros” e a falta da tal “padronização” são os principais fatores para isso.

    Um programa feito em Dos ou Windows 95 rodam até hoje sem problemas no Seven, isso para o desenvolvedor, e para o usuário é fantástico.

    Duvido que alguém consiga dar suporte para várias distribuições Linux para o seu produto, mesmo contando só as grandes (Ubuntu, Suse, Fedora) em suas várias versões.

    Estamos adquirindo um software, que o servidor e os terminais de retaguarda são em Linux, mas o fornecedor obriga a usar o Fedora 9 e os pdvs tem que ser windows em qualquer versão, se não for assim não tem negócio. Dai tem outro software na empresa que o fornecedor usa Ubuntu e só da suporte para o mesmo e ai como ficamos?

    O mundo real requer soluções praticas, “padronizadas”, nem que para isso temos que termos hardwares melhores, e hoje em dia isso não é mais problema.

    Thiago (usuário não registrado) em 22/10/2009 às 9:37 am

    Pelo amor de deus pessoal, já disseram aqui e vou repetir:

    O fatElf NÂO é, eu repito, NÃO é um substitudo para os ‘pacotes’ das distros e muito menos vem para abolir os gerenciadores de pacotes!!!

    Estão todos discutindo instalação de programas no windows x instalação de programas no linux quando o artigo não tem ABSOLUTAMENTE NADA a ver com isso!

    Os pacotes das distros continuariam a existir normalmente, a única diferença é que não se precisaria, por exemplo, fazer pacotes x86 e x86_64, poderia fazer um só que contenha os executáveis em fatElf para as duas plataformas.

    @Thiago
    Nesse caso eu acho que seria mais legal simplesmente melhorar o script de instalação do pacote de modo que ele saiba em que arquitetura o pacote esta sendo instalado e escolha os binários corretos, coloque eles no lugar e pronto. O artigo não tem nada a ver mesmo com sistemas de pacotes mas nós estamos usando isso daqui como fórum para discutir esse assunto que surgiu no meio dos posts, desculpe o mau jeito. :-D

    @Curioso
    Como programador eu não gosto dessa linha de pensamento de que memória e processador são abundantes e por isso podemos ficar tranqüilos e não se preocupar. Eu me preocupo com esse tipo de coisa devido a vários fatores, por exemplo: ainda tem muita maquina legada que não vai ser atualizada ainda por um bom tempo e eu quero rodar meu software nelas também, eu não posso exigir que o cliente atualize essas maquinas porque meu sistema requer mais recursos. Infelizmente eu ainda não tenho o cacife da MS para poder pedir isso (mas estou tentando chegar lá hehe). Existem também outros cenários, por exemplo, netbooks e sistemas menores que não tem tanta memória disponível, claro que com o passar do tempo isso deve mudar e essas maquininhas devem ganhar mais memória também mas por enquanto ainda é uma limitação. Também tem o problema de distribuir e atualizar sistemas via Internet, a largura de banda nunca é suficiente, eu realmente não acho legal baixar as duas versões e daí o sistema decidir qual quer usar, é mais interessante o sistema de pacotes já saber em que plataforma esta rodando e baixar a versão correta.

    Quando eu li o titulo e fui abrir o artigo eu estava imaginando algo como uma camada formada por uma maquina virtual de baixo nível que tratasse apenas das diferenças entre as arquiteturas, a gente compila para o assembly da maquina virtual e ela se encarrega de transformar isso em código de maquina na execução. Isso sim resolveria o problema e ainda com vantagens.

Este post é antigo (2009-10-21) e foi arquivado. O envio de novos comentários a este post já expirou.