Planeta Perl Brasil

Última atualização: 03/09/2010

August 16, 2010

Fred Recsky

Novo sistema para o Eee pc

Faz tempo que eu tenho um caso de amor com netbooks, agora com tablets :) apesar de não ter um ipad ainda. Mesmo assim tudo tem um começo meio e fim, e no caso meu eeepc com Xandros não dava mais, especialmente porque um netbook que acessa a internet com firefox 2 e flash 9 não rola.  Devido ao sistema como um todo estar com software "velho", não havia como instalar um flash novo e um navegador novo. Era hora do update. 

Mas qual distro escolher? Desde que eu voltei para o Mac Os, há dois anos atrás ( minha outra vida foi com um performa e mac os 7) não tenho mais saco para instalar linux em Desktops, é muito chato. Dificilmente instala e eu não tenho que punhetar o sistema de alguma forma. É wireless, é suporte a mp3 ou algum codec, etc. O micro também agora é muito mais usado pela minha esposa, tem que funcionar e pronto. 

Pesquisa rapida, temos opensuse, fedora, ubuntu, archlinux. Archlinux para minha namorada sem chance. Archlinux é o melhor "neo-slackware" mas é para geeks.  Quando ao fedora e ao opensuse, para mim eles continuam na mesma de 2/3 anos atrás, pacotes atualizados, suporte tal. Otimo trabalho porém é a mesma coisa de 3 anos atrás, eu queria uma coisa nova, e por incrivel que pareça a proposta do ubuntu me pareceu a melhor, agora era ver se compria o prometido. 

Baixei o ubuntu netbook , gravei num pendrive e instalei, e no final:

SDC11121.JPG

Funcionou tudo, na lata, quase chorei, serio. Pior, achou meu wireless, perguntou minha senha, e salvou, quando eu estou em casa conecta no meu wireless, quando estou fora pergunta qual rede. É isso, to feliz.

Tudo aquilo que voce precisa para seu eeepc 701 está no link acima, Ubuntu Netbook.
Enhanced by Zemanta

por Frederico Recsky em 16/08/2010

July 05, 2010

Fred Recsky

Scp não funciona mas ssh sim

A Shebang, also Hashbang or Sharp bang. This i...

Image via Wikipedia

Tive um problema bobo, que o scp parou de funcionar num dos meus servidores depois que eu fiz alguma coisa que eu não lembro o que era. De fato o ssh funcionava normalmente e o scp sempre entrava em loop infinito. 

Uma investigada no log me revelava que o scp parava quase no fim do processo, antes de iniciar a copia per si.  Eu resolvi dar uma procurada no google e vi alguns problemas relativos ao shell padrão definido para o usuario, no caso o shell como /bin/false ou outras coisas não "shell" davam problema.  Meu shell estava como /bin/bash mas como eu não tinha acesso de root eu tinha colocado uma chamada para o zsh no profile. 

Bastou remover a chamada e o scp passou a funcionar. Na pratica me parece que chamar algum outro shell ou programa interativo na inicialização do bash quebra o scp. Talvez de para testar se o shell esta sendo chamado local ou de um spc remoto e chamar ou não chamar o zsh. Preciso verificar.
Enhanced by Zemanta

por Frederico Recsky em 05/07/2010

May 31, 2010

Fred Recsky

Git Pro

Grafo juanjaen.blogalia.com

Image by JuanJaén via Flickr

Atualmente o Git é meu gerenciador de codigo fonte preferido, por muito, e eu venho estudando ele mas sempre usando local ou remoto no github. Já fazia um tempinho que eu queria usar o git remoto no meu servidor e asim como cvs e svn, tendo acesso remoto ao sistema de arquivos fica muito mais facil, você só precisa iniciar o repositorio, e depois acessar por ssh. 

No caso a dreamhost mantém uma wiki muito boa com varias dicas e receitas de bolo, incluindo uma para o git: http://wiki.dreamhost.com/Git. Mais facil que isso impossivel. Aproveitando o embalo também já fica a deixa que o grande livro de git (na minha opinião) também está ai "marcando" na internet, em http://progit.org/. Se você não leu ainda, vá correndo. 

Ainda assim Git Hub é o meu favorito, a ponto de eu pensar em comprar uma conta particular para o caso de eu precisar fazer alguma coisa proprietaria.  Especialmente porque o conjunto da obra está muito bom e já estrapolou o git per si, ele tem um monte de coisas legais como feeds, gists, follow, paginas, wiki.  Talvez seja a evolução natural do antigo source forge. 
Reblog this post [with Zemanta]

por Frederico Recsky em 31/05/2010

May 24, 2010

Fred Recsky

Gravar imagem iso no mac os

2006AUG121132

Image by bootload via Flickr

Eu vivo esquecendo de como gravar uma imagem iso no mac os. Especialmente porque é não trivial.  Mas esse link sempre salva meu dia, e merece um repost aqui:


\o/
Reblog this post [with Zemanta]

por Frederico Recsky em 24/05/2010

May 18, 2010

Fred Recsky

Em busca do Shell perfeito

Shell:  Original (1 of 3)

Image by cobalt123 via Flickr

Há algum tempo atrás no meu antigo blog, na época do fre.eti.br eu fiz alguns posts entitulados "em busca da distro perfeita", que era um frankstein de varias distros que existiam na época.  Passado quase 3 anos no desktop eu uso mac os e ele é o mais proximo do que eu tinha descrito.  Mas ainda tem um grande buraco que é quando eu uso o console, shell iterativo. 

O shell iterativo padrão das distros e dos unix em geral é muito cru, as unicas boas excessões que eu lembrom era o zsh do GoboLinux e o bash do archlinux.  Mesmo assim elas eram mais ou menos o que os principais desenvolvedores das distros gostavam e não o que eu queria :). Depois de alguns test-drives puramente subjetivos eu escolhi o zsh como padrão pessoal. No fundo no fundo o que eu quero não existe mas o zsh é o que se mostrou mais proximo do que eu queria e também pareceu o mais facil de configurar no que eu queria.

Ok, zsh é o meu padrão, cool, e agora, o que eu quero exatamente?

Primeiro um prompt legal, que mostre onde eu estou, e se eu estiver usando git mostre o branch, e eventualmente outra informação.  Nesse sentido eu copiei e colei de varios "ponto zsh" que eu vi por ai e cheguei nessa coisa joiada e melosa:

Screen shot 2010-05-18 at 11.34.17 AM.png

Ela mostra meu usuario, o host, o diretorio atual, o resultado do ultimo comando, e o git branch que eu estou atualmente.  Tem mais coisas que eu gostaria de adicionar mas por hora isso está ok. 

Depois eu realmente uso muito cd, e também digito um bocado e evito atalhos mneumonicos, como colocar na variavel $work um diretorio ou arquivo aleatorio. Isso porque eu uso muito o history e gosto dele bem claro. No caso cd  ~/Code/zsh_config  é muito mais claro que cd $zsh_work ou etc.

Nesse sentido eu uso uma variavel chamada cdpath. ela basicamente contem alguns diretorios para a busca padrão do cd, assim com:

cdpath=~/Code 

Sempre que eu digitar cd<tab>, o meu amado diretorio de codigos fontes estarão la.

Isso na verdade é só o começo, ainda na todo list tenho preprocessamento e postprocessamento do comando. Gostaria que quando eu digitasse cd Module::Build ele caisse no diretorio do modulo perl correspondente. E que o resultado de alguns comandos especificos fossem parseados diretamente.  Como em:

>comando bla:
foo bar bla bla

>comando2 $1 $3

Fosse traduzido como 'comando2 foo bla'.   Eventualmente talvez já exista algo pronto mas eu não descobri como fazer ainda. Antes que alguem fale do xargs, ele não é exatamente o que eu quero, pos eu gostaria que fosse magico, sem precisar explicitar o comando xargs.


Reblog this post [with Zemanta]

por Frederico Recsky em 18/05/2010

May 07, 2010

Fred Recsky

Desenvolvimento remoto e opensource

Working remote

Image by boboroshi via Flickr

Acho realmente engraçado como algumas coisas são, desde que voltei a olhar o meio de software proprietario percebi que existe uma dificuldade muito grande em se trabalhar remotamente com projetos proprietarios. Existe todo um conjunto de tecnicas sugeridas para que o desenvolvimento continue (e eventualmente descubra quando o programador está em casa dormindo). 

Sempre trabalhei remoto e de certa forma continuo (Perl), e trabalhei 3 anos em regime de home-office, de fato é natural para quem trabalha com open-source trabalhar remoto. A natureza de colaboração faz com que seu colega de projeto esteja num lugar remoto, eventualmente num outro fuso horario, num outro continente. A comunicação se da via irc, instant messager, telefone, email, listas de discussão, e programação em par até rola indiretamente (revisão de patches).

Quando eu vejo um post como esse do Jeff Atwood, eu realmente me espanto que em maio de 2010 ele descobre a roda:

I believe remote development represents the future of work. If we have to spend a little time figuring out how this stuff works, and maybe even make some mistakes along the way, it's worth it. As far as I'm concerned, the future is now. Why wait?

Ele descobriu a roda! Ainda em seu post ele faz uma misturança de comunicação a moda corporativa e o classico opensource, com lista, chat e telefone.  Talvez ele devesse fazer um estagio na Canonical.

Assim como eu acho que em geral (em geral!) produtos proprietarios tendem a ter melhor usabilidade, nada se compara a agilidade opensource em geral. Pode sair muita coisa do caldo se misturar os desenvolvedores ainda mais (mantendo o produto final aberto é claro :) ).


Reblog this post [with Zemanta]

por Frederico Recsky em 07/05/2010