2012/6/22 Alexei Znamensky <span dir="ltr"><<a href="mailto:russoz@gmail.com" target="_blank">russoz@gmail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><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></blockquote><div><br></div><div>Até pode ser, porém vc esta sujeito a problemas como classloader hell (quando alguem colocou mais de um jar com a mesma classe em versões diferentes e isso não é tão incomum assim) e a incompatibilitades com a JNI (e ai descobre que quem fez não se preocupou com outro sistema operacional). Mas seria otimo ter algo semelhante ao javaws para perl.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><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><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 class="im"><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><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 class="im">
<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><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><span class="HOEnZb"><font color="#888888"><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>
</font></span><br>=begin disclaimer<br>
Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Tiago B. Peczenyj<br>Linux User #405772<br><br><a href="http://pacman.blog.br">http://pacman.blog.br</a><br>