2012/6/22 Alexei Znamensky <[email protected]> > 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. >
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. > pacotes pode ser feito da mesma forma como outras linguagens fazem. Por >> exemplo, o debian distribui módulos perl pré-compilados a séculos, a Red >> Hat também, e tem muitas shops que criam pacotes .deb ou .yum de suas >> aplicações e dependências como mecanismo de deploy. O problema é que a >> comunidade não menciona muito essas soluções porque a maioria das >> pessoas que já estão dentro da comunidade não precisa delas, ou preferem >> > > 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. > > Para Solaris, o site onde normalmente se acha os pacotes é o > http://www.sunfreeware.com > lá, agora, a útlima versão de perl disponível é a 5.12.3, disponibilizada > em 17/Fev/2011. > > Para AIX, o site "padrão" para ferramentas Linux-like é o > > http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html > 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) > > >> compilar pra fugir da incompatibilidade binária. Eu particularmente >> prefiro essa abordagem, (isso não quer dizer que é necessariamente a >> "mais correta") e faço assim com todas as linguagens (inclusive as mais >> mainstream). Isso não é um problema específico do perl, mas de toda >> linguagem que fornece bindings pra bibliotecas escritas em outras >> linguagens. A diferença pra maioria das outras linguagens é que >> simplesmente não existe a cultura aqui de ter o trabalho de >> disponibilizar pacotes pré-compilados em N plataformas. >> > > 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. > > Mas, para um gestor, isso traz preocupações: > - tempo gasto (compilar versus instalar um binário pronto) > - 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. > - 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 > - 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. > > >> Talvez o que esteja faltando é suporte dentro do cpan para a >> distribuição desses pacotes. É uma questão de re-aproveitar compilações >> executadas por usuários do cpan e submeter um bundle com o blib dentro >> (é mais ou menos assim que funciona o sistema de testes hoje). Existem >> sistemas que já funcionam assim, como o brew e o macports. Alguém topa >> de criar e encarar o projeto? :) >> > > 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. > > 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). > > *** 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. > > Bom, to indo pegar meu vôo de volta pra casa. Fui! > > -- > Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org > GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C > http://www.flickr.com/photos/alexeiz | http://github.com/russoz > "I don't know... fly casual!" -- Han Solo > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > > -- Tiago B. Peczenyj Linux User #405772 http://pacman.blog.br
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
