É com muito orgulho que anuncio o lançamento da versão 2.5.3 do Pidgin! Fico cada vez mais orgulhoso de ajudar em um projeto tão bem sucedido e com tantos usuários. Você pode ver o changelog aqui.

É o quinto release com a responsabilidade de traduções minhas. Espero que gostem da nova versão e peço que se ncontrarem algum erro em alguma frase me comuniquem para que a correção possa ser feita.

As maiores mudanças estão nos protocolos XMPP e MSN, que estão entre os mais usados no Brasil . Então, se você utiliza um destes, sugiro que atualize seu Pidgin.

Gerar senhas é sempre uma coisa não tão trivial. Uma maneira razoável pode ser apertar teclas aleatórias do teclado, mas aí podem sair senhas com caracteres indesejados. O interessante seria uma ferramente que pudesse criar senhas aleatórias porém memorizáveis e com uma certa característica (com ou sem caracteres especiais,números, maiúsculas).

Uma ferramenta que comecei a usar para isso e que foi bastante útil foi o pwgen . Esse programa, de apenas 31kb, e que roda no shell, pode criar senhas com ou sem maiúsculas, com ou sem números, com ou sem símbolos, com ou sem caracteres ambiguos (por exemplo l, 1, 0 e O que podem ser confundidos com 1,l,O e 0 respectivamente). Por padrão ele gera senhas fáceis de serem memorizadas   e por isso não tão seguras como senhas "completamente" aleatórias (para senhas completamente aleatórias utilize a flag -s), por isso senhas geradas sem o argumento -s NÃO devem ser utilizadas em lugares nos quais podem haver ataques de força bruta para descobrir senhas (servidores de SSH por exemplo) .

Sua utilização é simples. Se não dado nenhum argumento e a saída for a saída padrão ele imprime 160 senhas de tamanho 8 organizadas em colunas. Se for utilizado somente um argumento, este argumento será o tamanho das senhas (obviamente, deverá ser um inteiro). Se forem utilizado dois argumentos, digamos x e y ,em ordem, x será o tamanho das senhas e y será o número de senhas.

Para personalizar as senhas geradas, pode-se utilizar algumas flags:

• -0, --no-numerals : Não inclui números nas senhas geradas;
• -1 : Imprime uma senha por linha;
• -A, --no-capitalize: Não inclui letras maiúsculas nas senhas geradas;
• -B, --ambiguous: Não usa caracteres que podem ser confundidos ('1' e 'l' por exemplo);
• -c, --capitalize: Inclui no mínimo uma letra maiúscula nas senhas geradas;
• -n, --numerals: Inclui no mínimo um número nas senhas geradas;
• -H, --sha1=arquivo: Utiliza um arquivo como "semente" para gerar senhas. Isso torna uma senha reprodutível (i.e. você pode gerá-la denovo), mas se esse arquivo for obtido por alguém que queira invadir sua máquina, suas senhas poderão ser descobertas;
• -s, --secure: Gera uma senha completamente aleatória (e portanto dificil de lembrar);
• -y, --symbols: Inclui no mínimo um caracter especial na sua senha. (Não gosto muito disso pois posso estar num teclado desconfigurado);

Para aprender mais, leia o man. Uma boa dica para uso é em scripts que administradores de sistema normalmente usam para adicionar usuários em uma rede.

Se você usa Debian, Archlinux ou Ubuntu basta procurar no seu gerenciador de pacote para instalar o pwgen.

È com muito orgulho que comunico o lançamento do Pidgin 2.4.2. A lista das mudanças para a versão antiga (2.4.1) pode ser vista no Changelog . Fico bastante orgulhoso de ter ajudado na tradução de uma versão de um aplicativo vencedor em sua categoria na eleição do Linux Journal.

Essa é a primeira versão do Pidgin cuja tradução foi realizada por mim, dando prosseguimento ao ótimo trabalho que vinha sendo realizado por Maurício Collares. Lembro que sugestões e relatórios de erros quanto a tradução são sempre bem vindos.

Depois de um dia de programação exaustiva...

rodrigo ~ $ history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
178 make
164 cd
159 ./Make.exe
131 ls
77 vim
49 su
45 cat
21 svn
20 valgrind
18 ps

O que ouço muito das pessoas é "Não sei nada de programação, nem tenho curiosidade de abrir um código fonte, por que devo utilizar um software aberto, se só quero uma coisa que funcione ?". Isso me motivou a escrever sobre isso.

Qual o comportamento esperado de um software? Se eu falo do Microsoft Word, é o de processador de textos, se do Skype, ligações telefônicas em aúdio. Um software fechado pode ter comportamentos mais obscuros que se conhece. Um caso que veio a tona é o iTunes para Windows, que ao fazer sua atualização, instalava junto (por padrão) o navegador da Apple safari. Uma prática, ao meu ver, bastante condenável e digna de um spyware. O que acontece com o Open Source? Uma prática dessas não acontece, pelo simples motivo de seu código ser aberto. Você, que não sabe programar, não precisar abrir o código do programa, basta pesquisar um pouco na internet, e qualquer coisa que tenha um comportamento fora do padrão virá a tona.

Usar software proprietário, implica basicamente em confiança em seus desenvolvedores. Confiança de que as coisas não terão um comportamento desonesto e mercadológico afim de se obter fatias maiores do bolo de usuários. Confiança de que dados do seu computador não serão enviados sem seu consentimento. Confiar em alguém que não confia que você saberá escolher o melhor navegador , ao meu ver, não é uma boa escolha.

No software open source, a confiança é mais clara: podemos ver o que o programa faz. Mesmo se você não souber programar, alguém que sabe irá ver e te dirá, pela blogosfera, se o programa é ofensivo e tem segundas intenções. Obviamente, nenhuma empresa solta um software open source que algo assim: é como dar um tiro em seu próprio pé.

Chega ao fim essa série de Posts sobre os modos de contribuir com Software Livre. E esse vai ao vivo do campus party!

Essa é a maneira mais fácil de se contribuir, pois não envolve nenhum esforço adicional. Se você não tem tempo sobrando, provavelmente será a maneira que você irá contribuir. Usar o software livre ajuda nos seguintes aspectos: quem produz o software livre se sente mais motivado (afinal programadores, tradutores e etc ficam felizes com suas obras sendo utilizadas), se você ficar satisfeito com o software, poderá indicá-lo para outras pessoas, que busquem um programa com tal funcionalidade podem baixá-lo gratuitamente e podem contribuir de muitas outras formas também.

Certa vez precisei de um programa para fazer diagramação (folhetos para uma install fest). Quais eram as minhas opções? Podia fazer um trabalho porco em um M$ Office ou OpenOffice (afinal processadores de texto não são para essas coisas) mas queria fazer algo legal. Podia utilizar o Adobe Pagemaker, considerado referência em diagramação, mas como estava fazendo uma install fest, preferi utilizar um Software Livre. Utilizei um software chamado scribus , um software bastante intuitivo de utilizar e que atendeu minhas necessidades. Poderia ter utilizado uma alternativa proprietária mas aí não poderia sugerir a quem necessitasse de uma ferramente dessas (o Pagemaker é caro, e não queria incitar à pirataria).

Não entendo do desenvolvimento de um software desse tipo, e este parece já estar traduzido. Nem uso com tanta frequência para ser um bug reporter e dar feedbacks. Logo contribui fazendo sua utilização. Não precisa nem usar Linux, existem muitos Softwares Livres que rodam no Windows, desde gravadores de CD, até editores de fotos e mensageiros instantâneos. E se você gostar recomende aos colegas, vizinhos, amigos e família.

Produzir software é uma tarefa bastante complexa. Por mais que você tenha um software simples, imaginar todos os possíveis usos e testar em toda e qualquer plataforma e qualquer sistema são tarefas desafiadoras e inviáveis. Fazer testes tão abrangentes é algo muito difícil e caro de se fazer. Uma estratégia é liberar versões instáveis para o público e ir recebendo relatórios de erros. Assim, mais pessoas testam, em muitas plataformas, em muitos sistemas e com muitos possíveis usos. Obviamente, você não irá colocar versões de teste em lugares de produtividade, pois erros são bastante esperados e podem te atrapalhar.

Um software livre normalmente, antes de uma versão estável, passa por muitos estágios de testes, que se esperam que tenham muitos erros. Se você quiser contribuir nesses estágios é bem simples: basta utilizar o aplicativo normalmente e caso dê algum erro, faça um relatório de erros, contando o que deu errado e descrevendo o que você fez para receber a mensagens de erro. Não utilize um relatório de erros para fazer reclamações do software, mas sim para informar os problemas que teve, e seja bem claro e tente escrever os passos exatamente como você fez para os desenvolvedores depurarem o programa. Mesmo as versões estáveis podem ter bugs, mas são menos frequentes e quase raros. Os ambientes grandes como o GNOME e o KDE, já embutem em seus programas um formulário que aparecerá cada vez que acontecer algum problema. Obviamente, você é livre para enviar ou não.

Um software que é utilizado normalmente para relatórios de erros é o Bugzilla da Mozilla Foundation que também faz o Firefox. O GNOME utiliza o Bugzilla para seus bugs, e é relativamente simples fazer um relatório de erro. Sò precisa saber relatar o bug em inglês. Assim que você fizer o relatório, um e-mail será enviado aos desenvolvedores que saberão de imediato sobre o bug. Não precisa se preocupar em colocar um bug repetido, é simples ao desenvolvedor dizer ao bugzilla que tal erro é uma cópia de outra. Isso não dá tanto trabalho de se fazer e ajuda o desenvolvedor a produzir um software melhor.

Foi se o tempo que para utilizar razoavelmente o Linux era necessário dominar o inglês. Hoje acredito ser possível instalar uma distribuição (Ubuntu) e utilizar o Firefox, o Open Office e o Pidgin somente sabendo falar português do Brasil. Acredito que a grande maioria das pessoas que ligam um PC só utilize programas como esses ( Internet Explorer, Microsoft Office e MSN Messenger) que no concorrente Microsoft Windows já estão traduzidos.

È um trabalho muito importante, pois podemos instalar Linux em escolas, tele-centros onde as pessoas geralmente não sabem inglês e assim disseminar ainda mais o uso de Software livre. E o conhecimento necessário é apenas um idioma ( e mais alguma experiência), logo é algo bem mais fácil que programar e que pode ser feito por muito mais pessoas.

Para começar, acho legal mexer com um projeto grande, onde já existem tradutores que vão te corrigir, te dar dicas e te ajudar no começo. Os ambientes Gnome e KDE possuem projetos de internacionalização bastante competentes e pode-se utilizar um sistema totalmente traduzido com esses dois ambientes. As equipes de tradução são bem organizadas e costumam contar (para alguns idiomas) com algumas dezenas de tradutores. As páginas das equipes costumam ter bastante informação do tipo "Como entrar para a equipe" além de algumas dicas de como traduzir. Obviamente sua tradução é sujeita a uma revisão para verificar a qualidade técnica, e caso necessário, corrigidos os erros. Não é trivial traduzir um programa, precisa-se respeitar padrões e manter uma consistência.

Para projetos menores, você pode mandar um email para o mantenedor pedindo para traduzir.  As páginas de Softwares Livres normalmente possuem esse e-mail disposto. Ele te dará as instruções de como fazer o download dos arquivos com as frases.

Primeiro post sério do ano.

O software livre, como já discutimos, não é algo produzido somente por empresas. Pessoas "normais" podem entrar e contribuir também. Mas não adianta enviar algo que apenas funcione. Tem que ter alguma qualidade técnica. POGramação não é bem vinda, afinal o código precisará de manutenção daqui a algum tempo e fazer a manutenção de POG é algo realmente complexo .

Programar parece o mais intuitivo, e é sobre isso que este post falará.Haverão outros sobre traduzir,feedbacks,bugs reports e usando.

Projetos bem organizados geralmente tem uma página com as coisas que precisam ser feitas, uma vez vasculhei a página do jogo Super Tux e lá eles têm uma TODO list com o que precisa ser feito. Se você souber fazer baixe o repositório, entenda como funciona lendo a documentação do desenvolvedor e alguma página do tipo "como contribuir" e faça o que foi pedido. Pronto, assim você contribui com software livre. Mas você precisa saber programar bem, não costuma-se aceitar códigos com muitas gambearras e POGramações.

A maioria dos projetos são feitos em C/C++. Programar nessas duas linguagens não é nada trivial, mas também não é nenhum bicho de 7 cabeças, existem muitos tutoriais na internet. Há bastante coisa em Python também, mas acho que vale mais a pena aprender C/C++. Se você for desenvolver jogos, seria legal você aprender uma biblioteca como a SDL ou OpenGL, muitos jogos são feitos utilizando estas bibliotecas. Se você for desenvolver aplicativos seria legal você aprender a utilizar o Dialog (se for fazer aplicativos para o terminal) ou Gtk ou QT (se for fazer aplicativos para o X). A maioria destes programas possuem bons tutoriais na net. Use o google, certamente achará muita coisa legal.

Abraços

Agora vou falar de programação. Uma prática no mínimo polêmica é a utilzação de Macros. Mas o que afinal são macros?

» Continue reading "Macros: Usar ou não usar ?"