<br><div class="gmail_quote">2012/6/21 Eden Cardim <span dir="ltr"><<a href="mailto:edencardim@gmail.com" target="_blank">edencardim@gmail.com</a>></span></div><div class="gmail_quote"><span dir="ltr">[...]</span></div>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Olha, sem querer chato mas, existem sim soluções para distribuição de<br>
pacotes pré-compilados e o processo de criação e distribuição desses<br></blockquote><div><br></div><div>Claro que existem. Como eu escrevi, nenhuma delas é (IMHO) atraente para o mercado em larga escala. Usa-se XS, principalmente, por dois motivos:</div>
<div><br></div><div>1) performance</div><div>2) linkar com biblioteca nativa</div><div><br></div><div>No caso 1), é menos mal porque não há dependências externas (ao Perl), então pode-se facilmente levar um módulo XS compilado de um sistema Linux para outro (claro, podem existir complicadores, estou ignorando-os para este argumento).</div>
<div><br></div><div>No caso 2), você não pode somente levar o seu módulo XS compilado. Você precisa lidar com a(s) biblioteca(s) externa. Você pode:</div><div>2.1) compilá-la</div><div>2.2) levá-la compilada junto (não sei se alguma ferramenta permite isso)</div>
<div>2.3) exigir que o usuário/administrador da máquina instale</div><div><br></div><div>Compare com um (perdoe-me senhor) Java Development Kit, que você faz download e copia para o servidor e *simplesmente executa*). Java pode ter seus N defeitos enquanto linguagem, mas do ponto de vista de um administrador de sistemas, é muito mais confortável que lidar com Perl.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
pacotes pode ser feito da mesma forma como outras linguagens fazem. Por<br>
exemplo, o debian distribui módulos perl pré-compilados a séculos, a Red<br>
Hat também, e tem muitas shops que criam pacotes .deb ou .yum de suas<br>
aplicações e dependências como mecanismo de deploy. O problema é que a<br>
comunidade não menciona muito essas soluções porque a maioria das<br>
pessoas que já estão dentro da comunidade não precisa delas, ou preferem<br></blockquote><div><br></div><div>Claro, na comunidade usamos muito Linux. No mercado, apesar de Linux em servidores estar sempre crescendo, ainda se utiliza muitos sistemas UNIX, principalmente em empresas grandes. Por UNIX, leia-se Solaris, AIX, HPUX, etc... e pacotes nativos, pré-compilados, de Perl para esses sistemas é algo bem difícil de se achar. O próprio interpretador perl não é encontrado em suas últimas versões.</div>
<div><br></div><div>Para Solaris, o site onde normalmente se acha os pacotes é o</div><div> <a href="http://www.sunfreeware.com" target="_blank">http://www.sunfreeware.com</a></div><div>lá, agora, a útlima versão de perl disponível é a 5.12.3, disponibilizada em 17/Fev/2011.</div>
<div><br></div><div>Para AIX, o site "padrão" para ferramentas Linux-like é o</div><div> <a href="http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html" target="_blank">http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html</a></div>
<div>lá, agora, a última versão disponível é a 5.8.2 (quando eu saí da IBM em 2009, no papel de admin, eu me lembro de usar esse perl nos ambientes em que eu trabalhava)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
compilar pra fugir da incompatibilidade binária. Eu particularmente<br>
prefiro essa abordagem, (isso não quer dizer que é necessariamente a<br>
"mais correta") e faço assim com todas as linguagens (inclusive as mais<br>
mainstream). Isso não é um problema específico do perl, mas de toda<br>
linguagem que fornece bindings pra bibliotecas escritas em outras<br>
linguagens. A diferença pra maioria das outras linguagens é que<br>
simplesmente não existe a cultura aqui de ter o trabalho de<br>
disponibilizar pacotes pré-compilados em N plataformas.<br></blockquote><div><br></div><div>Que é justamente o meu ponto: não existe algo como a versão binaria de perl, pre-compilado para N plataformas. Se falarmos de uma biblioteca "minima" para se trabalhar decentemente com Perl, nem se fale. Para nós que somos "computeiros" instalação por compilação (e compilações adjacentes) não é algo que assusta.</div>
<div><br></div><div>Mas, para um gestor, isso traz preocupações:</div><div>- tempo gasto (compilar versus instalar um binário pronto)</div><div>- repetibilidade (em uma equipe de N pessoas realizando instalações, podemos ter N compilações diferentes (em vários aspectos). Aí surge o overhead de criar um procedimento padrão de compilação para a ferramenta de programação (claro que o perlbrew ajudamuito nisso!). Isso presumindo que os ambientes de trabalho das pessoas da equipe são todos iguais - como geralmente, nas empresas, sempre há diferenças entre as máquinas e/ou sistemas operacionais, aumenta-se o número de variáveis para criar binários de Perl diferentes.</div>
<div>- rastreabilidade - em caso de m****, por exemplo um malware inserido num pedaço de código, você não tem como comparar coisas básicas como tamanho/data/digest de arquivos de uma máquina com o de outra (com outra compilação), com a segurança de que vai</div>
<div>- suporte (não-formal): como toda linguagem ou assunto, existe um fórum (ou mais) na internet que o time de desenvolvimento irá consultar para tirar dúvidas. No entanto, como não existe uma fonte única de binários, o suporte fica potencialmente mais difícil, pois as outras pessoas no(s) forum(ns) pode(m) ter compilado o perl/modulos de inumeras maneiras diferentes, em inumeras variantes de ambientes.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Talvez o que esteja faltando é suporte dentro do cpan para a<br>
distribuição desses pacotes. É uma questão de re-aproveitar compilações<br>
executadas por usuários do cpan e submeter um bundle com o blib dentro<br>
(é mais ou menos assim que funciona o sistema de testes hoje). Existem<br>
sistemas que já funcionam assim, como o brew e o macports. Alguém topa<br>
de criar e encarar o projeto? :)<br></blockquote><div><br></div><div>Chegamos exatamente ao mesmo ponto, por caminhos distintos. O que eu falei ao Garu à época foi: "se eu tivesse muito tempo disponível e nenhuma preocupação financeira", eu reservaria, tipo, um ano da minha vida para criar um site onde se faz build e disponibiliza pacotes binários de perl para N plataformas". Ou algo parecido ;-). Infelizmente eu não tenho essa disponibilidade. </div>
<div><br></div><div>No entanto, eu ajudaria a direcionar/mentorizar/suportar/blablablar algum voluntário a fazer isso. Por exemplo, no sourceforge tem (tinha, pelo menos) um build farm com vários OSs diferentes, deve ser possível utilizar essa estrutura para gerar os pacotes para sistemas mais "esdrúxulos" (believe, compilar free software em AIX é uma aventura).</div>
<div> </div><div>*** Ficou no draft durante o dia, e o Eden já complementou com alguns pensamentos. Mais tarde eu embalo na linha dele. Acho que temos uma idéia de desenvolvimento bem interessante aqui.</div><div><br></div>
<div>Bom, to indo pegar meu vôo de volta pra casa. Fui!</div></div><div><br></div>-- <br>Alexei "RUSSOZ" Znamensky | russoz EM gmail com | <a href="http://russoz.org" target="_blank">http://russoz.org</a><br>GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C<br>
<a href="http://www.flickr.com/photos/alexeiz" target="_blank">http://www.flickr.com/photos/alexeiz</a> | <a href="http://github.com/russoz" target="_blank">http://github.com/russoz</a><br>"I don't know... fly casual!" -- Han Solo<br>