me.age++

Apesar de estar um pouco atrasado, esse é um post para dizer que cheguei aos 30 anos. Sim, sou um rapaz 3.0 agora!
Sem muito mais o que adicionar ou falar, mando duas fotos minhas em na Star Wars Expo Brasil. Afinal de contas, Star Wars também tem a minha idade.

Powered by ScribeFire.

Meme: 5 livros para ler e 1 para esquecer (versão turbinada)

Via Terramel, descobri essa meme do Blog do Lucho, e resolvi participar.

O problema é que eu sou um Leitor voraz (sou do tipo que me sinto pelado se saio de casa sem um livro). Portanto, decidi dar uma “turbinada” e colocar vários livros para ler e um para esquecer, e várias séries de livros para ler e uma para esquecer.
Bem, começando com os livros. Para ler, indico:

• Shibumi (Trevanian): Também da lista do Terramel, esse livro conta a história de Nicholai Hel, o mais hábil assassino do mundo, e de como ele tem que lutar para ter o direito de viver em paz quando decide abandonar essa vida. Um guerreiro, um místico, forjado na sabedoria do Go e dotado da arte Nu/Matar e na exploração de cavernas, ele fará de tudo para proteger a paz pessoal que tanto deseja;
• A Profecia Celestina (James Redfield): Alguns acham que esse livro é apenas mais um antecessor de “O Segredo”, mas na realidade é um livro bastante interessante. Por trás da ficção dos Manuscritos, você acaba aprendendo como funciona a mente das pessoas e como tornar-se uno com o que interessa;
• Meijin ou The Master of Go (Yasunari Kawabata): A história da última partida de Go do grande Mestre Honinbo Shusai, contra Minoru Kitani, “romanceada” de maneira a, ao mesmo tempo em que se preserva o fato histórico, se tem um romance que mostra o fim de uma era no Japão e o início de outra, e todos os impactos desse evento;
• O Pequeno Príncipe (Antoine de Saint-Exupére): é um clássico, eu sei, e muitos criticam ele com a famosa “é livro de Miss Universo”. Mas é um livro que fala sobre aquelas coisas puras da infância e que realmente fazem a diferença, sobre amizade, carinho, inocência e por aí afora;
• Hackers and Painters (Paul Graham): para quem quer entender mais sobre a revolução da Internet e como, de uma hora para a hora, ser nerd tornou-se chique, Paul Graham ajuda a desvendar isso nesse livro. Uma série de artigos do mesmo, ele mostra que hackers (legítimos, não invasores de sistemas) não fazem coisas para “fazer bonito” ou “ser descolado”, mas sim porque acreditam que elas são boas;
• Stardust (Neil Gaiman): Um pouco confuso, mas Stardust é um exemplo de fantasia coerente e bem amarrada. É a história de Tristan Thorn, que vive em um vilarejo próximo a um portal para Faerie, o reino das fadas. Ao ver uma Estrela Cadente, Tristan promete levá-la à mulher que amava (e que apenas zombava dele). Quando ele entra em Faerie, porém, cada vez mais ele vai se perguntando sobre os sentimentos dela por ele e vice versa;

E fuja de:

• Código Da Vinci (Dan Brown): Esse livro é o caso típico de livro que é bom até o último capítulo, onde “a maionese desanda”. Simplesmente dispensável, não vale a penas nem comentar direito;

Quanto a séries de livros, leia:

• Duna (Frank Herbert): É incrível a coerência da série Duna - os livros são bem estruturados, bem amarrados e a trama é bem-elaborada. Os personagens não são preto-no-branco e têm motivações complexas. Apesar de ser “Ficção Científica”, é impressionante como existe a preocupação com a política, ecologia e história do cenário. É a saga de Paul Atreides, o Moad’dib, o resultado de séculos de programas de reprodução das Bene Gesserit, conspiradoras e “bruxas” com habilidades sobre-humanas desenvolvidas pelo treinamento e pela genética. Uma série, acima de tudo, sobre o que é ser humano;
• Fundação (Isaac Asimov): Como quase tudo que o “Bom Professor” escreveu, Fundação é uma ótima série sobre as conseqüências da tecnologia na vida humana e sobre as opções que fazemos. A sutileza das opiniões sociais de Asimov ficam dançando diante de sua vista;
• Mochileiro das Galáxias (Douglas Adams): qualquer mingo (amigo) sancha (conhece) essa série desse cara dupal (animal) chamado Douglas Adams. Metido em enrascadas espaciais desde que consegue escapar da demolição da Terra para dar lugar a uma via hiper-espacial, o inglês Arthuur Dent vive aventuras e desventuras extremamente bizarras na companhia de Trilian, a outra sobrevivente da demolição da Terra, dos alienígenas Ford Prefect e Zaphod Beeblebrox e de Marvin, o Andróide Paranóide. Douglas Adams sem favor nenhum chuta o balde da ficção científica e tira sarro de tudo e de todos envolvidos com a mesma. Ótima leitura para descontrair, mas com algumas verdades nos esperando lá no fundo;
• Discworld (Terry Pratchett): Discworld está para a Fantasia Medieval como Mochileiro das Galáxias está para a Ficção Científica. O mundo de Discworld não é o típico mundo de Fantasia Medieval, a começar por ser um Disco apoiado nas costas de quatro elefantes que estão apoiados nas costas de um astroquelônio (uma tartaruga de tamanho astronômico, para traduzir para o português). Nesse mundo bizarro, conhecemos vários personagens inusitados, como Cohen o Bárbaro, a Vovó Cera-do-Tempo (a Bruxa mais Cara-de-Maçã que você pode imaginar) e Rincewind, um mago atrapalhado. As aventuras desses personagens são regadas com humor, até mesmo nas terríveis situações quando O Morte (não, você não leu errado: em Discworld, Morte é homem, e não uma mulher) chega para levar-lhe embora. Chute no balde completo com os estereótipos da Fantasia Medieval (como uma Bruxa hiper-ativa que tem dentes perfeitos, o que não a torna respeitável como bruxa);

e fuja de:

• Desventuras em Série (Lemony Snicket): sinceramente, uma série pode ter muitos episódios onde os heróis se ferram, mas Lemony Snicket parece ter se superado, pois nessa série os heróis se ferram o tempo todo. Simplesmente dispensável;
• Artemis Fowl (Éoin Coiler): um caso clássico de idéia boa que flopa (dá errado), Artemis Fowl é a história do garoto de mesmo nome que é treinado para tornar-se o maior ladrão do mundo. Porém, com o tempo ele começa a se envolver com criaturas mágicas que vivem abaixo da terra, como Centauros e Duendes. A idéia é boa, e a mistura de magia e tecnologia das criaturas mágicas é muito divertida, mas existe algo nele que não amarra legal e acaba fazendo a leitura ser desagradável;
• Fronteiras do Universo (Phillip Pullman): Começando em A Bússola de Ouro, passando por A Faca Sutil e terminando em A Luneta Âmbar, essa série conta a história de Lyra, uma garota de uma Terra de uma outra dimensão, onde as pessoas possuem companheiros “animais” chamados de daemons que as ajudam quando as coisas estão ruins. Porém, ela se envolve em uma trama que coloca em risco todo o Universo e percebe-se que ela é a chave para o destino de todas as dimensões. Uma crítica ao fundamentalismo cristão, acaba pecando pelos personagens que são mal fundamentados quanto às suas intenções, ao ponto de você chegar e não saber quem é herói e quem é vilão, sem falar no final trash. De qualquer modo, não vale a pena, pois, assim como Artemis Fowl, ele é uma boa idéia que acabou dando errado;

Rápida: encodando vídeos para MP5 Player no Linux

A quase um ano atrás, escrevi um post sobre um MP4 que eu tinha e sobre como usá-lo com o Linux. Bem, a verdade é que ele acabou pifando e tive que comprar um outro para assistir meus animes (dá para fazer isso também usando o Nintendo DS que eu comprei, mas falarei sobre isso em uma outra oportunidade). No caso, acabei adquirindo um MP5 desses mais genéricos, que você compra nesses camelódromos e outlets no Brasil (no caso, a Sogo Plaza). Bonitinho, aceita cartões de memória e usa vários tipos de vídeos, entre eles o MP4 (provavelmente na formatação do iPod) e AVI (DivX), além do nativo 3GP (no qual ele também filma).

Na realidade, comprei esse MP5 mais pela simplicidade. De qualquer modo, gostei dele pois é simples operar ele no Linux. Ele monta automaticamente e os dispositivos são reconhecidos sem necessidades de hacks como o do meu antigo RockChip. Ele possui um conjunto de diretórios onde você deve dispor seus arquivos:

• audio - Aqui você deve colocar seus arquivos de áudio em MP3. Arquivos gravados com o recurso de gravação de voz virão para cá em formato .WAV;
• ebook - Aqui você pode colocar seus ebooks em TXT;
• game - Nesse local você pode colocar ROMs de jogos de Nintendo 8 bits para jogar no MP5;
• picture - Aqui ficam suas imagens, tanto as que você subiu quanto quaisquer fotos que você tirar com a câmera VGA do mesmo;
• video - Aqui você guarda seus vídeos. Vídeos gravados com o recurso de filmagem do mesmo são salvos aqui em formato 3GP;

E para encodar vídeos? Os formatos utilizados são MP4, 3GP e AVI (DivX). Como sugestão pela facilidade, utilize o script zepo_encode (disponível nesse site). Esse script depende apenas do MPlayer e converte de qualquer formato aceito pelo MPlayer para AVI especialmente preparado para o MP5. Para usar o script, utilize o comando:

$ ./zepo_encode [entrada] [saída]

Onde saída recebe extensão automaticamente. Lembre-se de colocar o zepo_encode em um diretório do $PATH do ambiente e definir permissões de execução para o mesmo. Após converter, basta copiar o arquivo resultante para dentro do diretório video do MP5 ou de um cartão de memória. Com esse script e algum hack de Shell você pode encodar vários vídeos e colocá-los no MP5 enquanto você vai dormir…
Para que você tenha uma idéia de se essa dica lhe é útil, abaixo segue a saida do lsusb -v para ele:

Bus 002 Device 003: ID 04fc:5563 Sunplus Technology Co., Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0×04fc Sunplus Technology Co., Ltd
idProduct 0×5563
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0×82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0×0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0×03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0×0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0×84 EP 4 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0×0040 1x 64 bytes
bInterval 1

Por que não me surpreendo? Documentos produzidos no MS Office 2007 NÃO SÃO COMPATÍVEIS com DIS 25900 (OOXML)

Certas coisas, quando você lê, não te surpreende. Não interessa o que, mas certas coisas, ao lê, não te surpreende. No meu caso foi ler que, via Groklaw, que documentos MS Office 2007 não são compatíveis com o ISO 25900, também conhecido como OOXML.

Surpreendente? Calma que a coisa ainda vai fiar pior!!!

Bem, tudo começa quando Alex Brown, um dos pais dessa aberração chamada OOXML, decide fazer um teste após receber os schemas atualizados com as modificações sugeridas no BRM.

Griffin Brown Weblog - OOXML and Office 2007 Conformance: a Smoke Test

I was excited to receive from Murata Makoto a set of the RELAX NG schemas for the (post-BRM) revision of OOXML, and thought it would be interesting to validate some real-world content against them, to get a rough idea of how non-conformant the standardisation of 29500 had made MS Office 2007.

Not having Office 2007 installed at work (our clients aren’t using it – yet), the first problem is actually getting a reasonable sample for testing. Fortunately, the Ecma 376 specification itself is available for download from Ecma as a .docx file, and this hefty document is a reasonable basis for a smoke test …

Resumindo aqui, uma vez que a tradução seria longa e desenecessária: ele recebeu os novos schemas do OOXML atualizados para considerar as modificações do BRM e decidiu validar algum conteúdo “real” para ter uma idéia de o quão não-padronizado um arquivo .docx produzido pelo MS Office 2007 era. Como ele não tinha nenhum Office 2007 à mão, ele utilizou as próprias especificações do OOXML segundo a ECMA, que foram publicadas em… .docx.
Perceba a fina ironia: o que deveria confirmar o padrão acabou tornando-se um caso de uso negativo contra o mesmo. Acha engraçado? Eu não.

Griffin Brown Weblog - OOXML and Office 2007 Conformance: a Smoke Test

The main document (”document.xml”) content for Part 4 of Ecma 376 weighs in at approx. 60MB of XML. (…) So we have a document and a RELAX NG schema. All that’s necessary now it to use jing (or similar) and we can validate (…) The STRICT conformance model is quite a bit different from Ecma 376, essentially because most of that format’s most notorious features (non ISO dates, compatibility settings like autospacewotnot, VML, etc.) have been removed. Thus the expectation is that existing Office 2007 documents might be some distance away from being valid according to the strict schemas.

Sure enough, jing emitted 17MB (around 122,000) of invalidity messages when validating in this scenario. Most of them seem to involve unrecognised attributes or attribute values: I would expect a document which exercised a wider range of features to generate a more diverse set of error message.

Traduzindo

Os conteúdos do documento principal (”document.xml”) da Parte 4 do ECMA 376 [a primeira versão do OOXML] tinham algo em torno de 60 MB de XML (…) portanto tinhamos um documento e um schema em formato RELAX NG. Tudo o que precisávamos portanto era usar o jing [validador de documentos segundo schemas RELAX NG feito em Java] ou outros sistemas similares e poderíamos validar o documento (…) O modelo de conformitade STRICT é um tanto diferente do ECMA 376, essencialmente por causa de que os mais notórios recursos (como datas não-ISO, informações de compatibilidade como os do autospacewotnot, VML, etc.) forma removidos. Desse modo a expectativa era de que documentos Office 2007 deveriam estar longe de serem considerado válidos segundo schemas restritos.
Obviamente, o jing retornou algo em torno de 17MB (ou por volta de 122.000) de mensagens de erro enquanto validando o documento nesse cenário. A maior parte deles tem a ver com atributos ou valores de atributos não reconhecidos: imagino que um documento que utilize uma gama maior de recursos provoque uma gama maior de erros. (Grifos meus)

Note que o próprio autor assume que (1) documentos do MS Office 2007 não estavam longe de serem considerados padrão e (2) que documentos que usassem mais recursos provavelmente gerariam mais mensagans de erro.
Agora, a pergunta é: se o formato foi padronizado, quanto tempo o usuário do Office 2007 deveria esperar para ter documentos DIS-25900 compliant, uma vez que o Office 2007 é a “implementação de referência” do OOXML? Como comparação, o OpenOffice.org é a “implementação de referência” do ODF, e levou apenas duas semanas para que o mesmo gerasse documentos ODF compliant.
No mesmo post, o autor mostra um outro schema, TRANSITIONAL, que é mais “liberal” que o STRICT. Mesmo assim, o documento gerou mensagens de erro relacionadas a uma tag específica. As concluões? O próprio autor coloca:

Griffin Brown Weblog - OOXML and Office 2007 Conformance: a Smoke Test

• Word documents generated by today’s version of MS Office 2007 do not conform to ISO/IEC 29500
• Making them conform to the STRICT schema is going to require some surgery to the (de)serialisation code of the application
• Making them conform to the TRANSITIONAL will require less of the same sort of surgery (since they’re quite close to conformant as-is)

Traduzindo:

• Documentos do Word gerados pela versão atual do MS Office 2007 não são compatíveis com o ISO/IEC 29500
• Torná-los compatíveis com o schema STRICT demandaria alguma “cirurgia” nos códigos de (de)serialização de objetos na aplicação
• Torná-los compatíveis com o schema TRANSITIONAL demandaria menos “cirurgia”, uma verz que ele está mais próximo da compatibilidade como-está;

Para resumir:

1. Documentos do Word 2007 não são compatíveis com o OOXML;
2. Torná-los compatíveis fielmente ao padrão OOXML (ISO 29500) demandaria grandes modificações no código do Office 2007;
3. Torná-los compatíveis ao schema de transição demandaria poucas modificações, uma vez de que este schema está mais próximo do Office 2007;

Será que sou só eu que ainda acredito que isso não passou de um motivo para a MS arrumar um selinho de ISO para seus produtos e ainda assim manter seu lock-in nos documentos?
Além disso, será que a própria Microsoft não irá sabotar esse “padrão ISO” por si? O autor do post que estamos comentando é otimista (talvez de maneira quase Polianística):
Griffin Brown Weblog - OOXML and Office 2007 Conformance: a Smoke Test

Given
Microsoft’s proven ability to tinker with the Office XML file format
between service packs, I am hoping that MS Office will shortly be
brought into line with the 29500 specification, and will stay that way.
Indeed, a strong motivation for approving 29500 as an ISO/IEC standard
was to discourage Microsoft from this kind of file format rug-pulling
stunt in future.

Ou seja

Dada à habilidade da Microsoft de melhorar o formato do Office XML por meio dos service packs, espero que logo o MS Office seja alinhado com as especificações 29500 e assim permaneça. De fato, um dos maiores motivadores para a aprovação do 29500 como um padrão ISO/IEC foi como uma forma de desencorajar a Microsoft quanto a essa atitude de discrepâncias em relação ao padrão no futuro.

Diferentemente do autor do post em questão, sou mais cético: o retrospecto histórico, inclusive durante o processo de padronização do OOXML, da MS joga contra ela. Porém, espero realmente que, caso a MS continue por essa vereda, que ela ao menos alinhe-se ao padrão que, por mais ruim que seja, ela ajudou a criar. Mas até lá, vou continuar atento, observando isso e evitando ao máximo o OOXML.

Rápida: Quadrinhos Open-Source

Divulgando os quadrinhos da Free Software Magazine:

Dica rápida: Restaurando o ícone da Lixeira no KDE

Olá!

Às vezes acontece de você entrar no KDE e estar sem o ícone de Lixeira. Embora o acesso via Konqueror (trash:/) ajude, ele não tem todos os recursos que você precisa. Uma solução é a seguinte: abra o seu editor de texto predileto (no meu caso é o EMACS, mas fica a seu critério) e escreva o seguinte código nele:

[Desktop Entry]
Type=Link
URL=trash:/
Encoding=UTF-8
Icon=trashcan_full
EmptyIcon=trashcan_empty
Name=Trash
Name[pt_BR]=Lixo
Comment=Contains removed files
Comment[pt_BR]=Contém arquivos removidos
OnlyShowIn=KDE

Salve esse documento em ~/Desktop/trash.desktop. Isso deve resolver o problema.
Via VivaOLinux.

O papel da comunidade no Linux e no Software Livre

De quando em quando aparece alguém perguntando qual o papel da comunidade no Linux e no Software Livre. Esse tipo de reflexão feita de tempos em tempos é extremamente importante, uma vez que cada um de nós fazemos parte de algo maior, por menos que nos demos conta disso.
Em geral, quando pensamos em uma “comunidade do Software Livre”, pensamos em uma comunidade de desenvolvedores de software livre, certo? Bem, parece que as coisas estão mudando e mudando bem rápido, ao menos quanto ao Linux:

Linux: qual o verdadeiro papel da comunidade? | LonelySpooky’s Blog

Sim, é isso… estudos recentes da “The Linux Foundation” evidenciam o que muita gente já sabia: são as empresas que mandam no desenvolvimento do Linux. Pelas estatísticas, há mais de 1000 programadores dando duro em escrever o código do kernel e entre 70% e 95% desses desenvolvedores são pagos para fazê-lo e mais de 70% dessas contribuições são feitas por programadores que trabalham em grandes empresas.

O que é uma verdade. Mas antes que pensem que essas empresas são boazinhas ou “mecenas”, vamos aos fatos: nenhuma IBM, Sun ou Oracle é boazinha. Elas sabem que o jogo do software livre tem regras claras. Por tais regras, ela sabe o que podem ou não fazer ou deixar de fazer, de uma maneira muito mais clara do que as EULAs do software proprietário. Desse modo, fazer coisas que permitam a elas ganhar dinheiro não é apenas ético, mas simples e barato, pois o Software Livre é uma região “livre de advogados”.
Isso é um fato. As empresas realmente estão se conscientizando do valor do software livre. Agora, eu discordo ao menos em parte com essa idéia de que estão pegando desenvolvedores de graça:

Linux: qual o verdadeiro papel da comunidade? | LonelySpooky’s Blog

Muitas empresas inteligentes perceberam que abrir o código de seus produtos facilita o desenvolvimento porquê, verdade seja dita, não há nada como ter milhares (ou até milhões) de programadores trabalhando de graça para implementar melhorias ao seu produto.

OK… Como se diz, “não existe almoço grátis”. Na realidade, ao oferecerem seus códigos, essas empresas já estão pagando os desenvolvedores. Parece loucura?  Talvez sim. Mas é importante levar em consideração a característica de gift economy (ou economia da doação) envolvida no software livre, o que pode explicar e permitir um nexo “capitalista” nessa história toda. Pode-se imaginar inclusive que continuamos tendo um contrato aos moldes capitalistas, mas com uma moeda de troca diferenciada: o código passa a ser a moeda de troca.
Duvida? Vejamos o que David Wheeler, consultor do Departamento de Defesa Norte-Americano tem a nos dizer:

More than a Gigabuck: Estimating GNU/Linux’s Size

In particular, it would cost over $1 billion ($1,000 million - a Gigabuck) to develop this GNU/Linux distribution by conventional proprietary means in the U.S. (in year 2000 U.S. dollars).

traduzindo:

More than a Gigabuck: Estimating GNU/Linux’s Size

Em particular, custaria mais de 1 bilhão de dólares (Gigabuck() para desenolver essa distribuição do GNU/Linux [no caso, é o Red Hat Linux 7.1, lançado no ano 2000] nos Estados Unidos usando os métodos tradicionais do Software Proprietário (segundo os custos no ano 2000)

Ou seja, o software livre, por meio do gift economy, faz circular conteúdos (no caso, software), cujo o valor para ser produzido segundo metodologias tradicionais seria enorme. Desse modo, podemos imaginar que, ao ceder seus códigos a desenvolvedores segundo licenças livres/abertas, uma empresa obtem como retorno um código de alta qualidade, ao mesmo tempo em que “paga” os desenvolvedores com código de alta qualidade e/ou interessante.
Parece bizarro? Outro trabalho seminal, esse de Eric S. Raymond, “A Catedral e o Bazar”, contém algumas respostas para isso:

A Catedral e o Bazar: O Correio Deve Ser Enregue

1. Todo bom trabalho de software começa colocando o dedo na ferida de um programador.

Talvez isto deveria ter sido óbvio (um antigo provérbio diz que “A necessidade é a mãe da invenção”) mas muitas vezes os programadores gastam seus dias buscando retorno em programas que eles não necessitam nem gostam. Mas não no mundo do Linux — o que pode explicar porque a qualidade média do software originada na comunidade de Linux é tão alta.

Assim, eu me lancei imediatamente com o ímpeto de codificar um novo cliente POP3 para competir com os existentes? De maneira alguma! Eu olhei com cuidado os utilitários POP que eu tinha à disposição, perguntando-me “qual deles é o mais próximo do que eu quero?”.

Porque…

2. Os programadores bons sabem o que escrever. O grandes sabem o que rescrever (e reusar).

Embora eu não me considere um grande programador, eu tento me passar por um. Uma importante característica dos grandes é a preguiça construtiva. Eles sabem que você ganha um `A’ não por esforço, mas por resultados, e é quase sempre mais fácil partir de uma boa solução parcial do que do nada.

Linus Torvalds, por exemplo, não tentou realmente escrever Linux do nada. Ao contrário, ele começou reusando código e idéias do Minix, um pequeno sistema operacional Unix-like para máquinas 386. Eventualmente todo o código Minix se foi ou foi completamente rescrito — mas quando estava lá, forneceu as bases para o infante que se transformaria no Linux.

Códigos bem-escritos ou interessantes são sempre uma boa “forma de pagamento” para programadores, uma vez que as necessidades são muitas e podem ser supridas por uma “boa alma” que precise ela própria de inovação e decida-se a “pagar” por bons desenvolvedores. Casos como o Mozilla Firefox, OpenOffice.org, MySQL, Apache, Websphere e outros comprovam isso. Desse modo, podemos perceber que (1) nenhuma empresa está nesse jogo como um “mecenas”, (2) todo desenvolvedor sabe que grandes empresas estão usando seus códigos para isso e (3) normalmente os desenvolvedores não esquentam a cabeça, pois já “receberam seu pagamento” na forma de bons códigos para estudo ou desenvolvimento de soluções necessárias às suas atividades.
Mas o fato de termos muitos programadores de Software Livre trabalhando para empresas acabou com o papel da comunidade? Eu acredito que não, como já disse várias vezes:

Os usuários estão no Linux… E nós, estamos prontos para isso? « Linux… e mais coisas

É importante que sempre nos lembremos que, um dia, todos fomos novatos, com dúvidas bobas sobre como montar um dispositivos, compilar um programa ou carregar o módulo de kernel para aquela placa de rede que não funciona nem a pau. Essas coisas são úteis nesse momento. É lembrarmos que mesmo Jesus Cristo foi humilde e nos lembrou sobre isso ao lavar os pés dos apóstolos.

Não estou defendendo que se preste consultoria de graça, mas acho muito importante lembrarmos que somos parte de uma comunidade. Qualquer besteira que fizermos, qualquer resposta ríspida que oferecermos, seremos nós que iremos pagar caro.

Ajudar as pessoas no início do GNU/Linux é difícil. Algumas vezes pode ser que nem mesmo nós saibamos as respostas para as perguntas (não, aqui “42″ não é uma resposta válida… :P). Não precisamos responder com coisas do tipo “RTFM” ou “Google is your friend“. Educação e respeito pela “novatice” alheia pode ser uma coisa muito mais util para o GNU/Linux do que ser um über-hacker.

Auxiliar as pessoas é uma característica do ser humano: é parte de nossa própria natureza. Esse é um trabalho que a comunidade pode e deve exercer com certeza. A idéia de ser parte de um grupo nesse caso é tão fundamental que, na série (muitas vezes esquecidas) dos Linux HOWTOs (parte do Linux Documentation Project), existe o Linux Advocacy mini-HOWTO (traduzindo, o mini-guia de Como Defender o Linux). nele, temos várias dicas sobre como defender o Linux. Algumas que acho interessantes:

• Compartilhar experiências boas e ruins com o Software Livre;
• Se disponibilizar para fazer apresentações sobre Software Livre;
• Mostrar para as pessoas que existem softwares livres bastante maduros para vários tipos de necessidades;
• Distribuir CDs e livros de Linux qunado você não mais os usar.

Além disso, nem só de desenvolvimento vive o software livre. Vejamos algumas formas de ajudar:

• É bom em inglês e/ou outros idiomas? Traduções são sempre bem vindas.
• Tem boa redação? Muitos software sofrem de uma carência de boa documentação e aqui você pode ajudar.
• É bom com desenho? Muitos softwares precisam de logos e artes para divulgação.
• Gosta de “viver desafios”? Bug-tracking (descoberta e divulgação de bugs) é algo bastante importante. E isso vale para todos: qualquer bug pode acontecer a qualquer momento e isso pode ajudar a aumentar a qualidade do software.
• Precisa de recursos específicos? Sugira-os! Os desenvolvedores podem achar uma boa idéia e os implementar.
• É bom com o público? Seja um evangelista do software livre! Divulgue o software e mostre que ele é bom!
• Ofereça apoio financeiro a projetos interessantes. Programadores podem não precisar de Ferraris, mas precisam de feijão e arroz;
• É experiente? Proponha-se a ensinar software livre, a instalar e configurar e ajudar novos usuários.
• Teve um bom caso com algum hardware novo? Divulgue. Divulgue todos os procedimentos para o fazer funcionar, scripts que tornem fácil seu uso, etc…

Acho que cada vez mais precisamos lembrar que o software livre depende sim de uma comunidade em sintonia, que auxilie na divulgação e que aprecie as contribuições uns dos outros.
E você, o que está fazendo?

Powered by ScribeFire.

Pegando carona na Meme: 10 comandos mais usados

Via Christiano Anderson:

No serviço, usando Fedora Core 6:

[login@estacao .]$ history|awk ‘{a[$2]++ } END{for(i in a){print a[i] ” ” i}}’ |sort -rn|head
69 cp
61 java
50 ls
46 cd
28 df
27 sed
25 cat
23 ~/teste.php
23 tar
21 rm

Em casa, usando Debian Lenny:

fecosta@hufflepuff:~$ history|awk ‘{a[$2]++ } END{for(i in a){print a[i] ” ” i}}’ |sort -rn|head
81 cd
56 cp
44 su
38 df
36 ls
28 rm
26 dmesg
24 chmod
19 du
14 for

Em casa, usando Debian Lenny, como superusuário:

hufflepuff:~# history|awk ‘{a[$2]++ } END{for(i in a){print a[i] ” ” i}}’ |sort -rn|head
14 apt-get
9 exit
9 cd
7 dpkg
5 tar
4 gpg
4 df
3 /etc/init.d/tor
2 lsof
2 ls

Powered by ScribeFire.

Rápidas: Embalagem de CD em Origami

Acabei de perceber a utilidade de uma coisa que vinha fazendo mas depois parei, que é embalagens de CD em Origami. Elas ajudam pra caramba, principalmente se você não tem um plástico protetor ou uma caixinha de CD à disposição. E o pior: não é muito complexo de ser feito. Embora tenha uma ou duas partes que são mais complexas, não é muito difícil, e mesmo pessoas com baixa coordenação motora (como EU) conseguem uma embalagem de CD razoável com uma certa facilidade. Além disso, você pode reaproveitar folhas que estejam sobrando em sua casa ou escritório para fazer isso.
Para maiores instruções (em inglês, com fotos), veja nesse site e nesse outro site.

Powered by ScribeFire.

Bons tempos que nunca morrem: as primeiras edições da Revista do Linux.

Ahhh… O começo de tudo!

Algumas coisas deixam saudade naqueles que passaram pelas coisas. Nintedinho, Bambalalão e Balão Mágico são algumas delas para mim. Dragon Ball Z, Defensores de Tóquio (o original) e OS/2 são outras.
Mas não é sobre elas que eu quero falar, e sim sobre a saudosa Revista do Linux. No final da década de 90 (literalmente pois foi em Novembro de 99), saía a primeira edição da pioneira Revista do Linux. Apoiada pela então maior empresa de Linux do Brasil, a Conectiva (depois fundida à Mandrake Software, virando a Mandriva), a Revista do Linux foi uma iniciativa pioneira: na época, tinhamos muito pouco não apenas no Brasil, mas em todo o mundo quanto a revistas voltadas à Software Livre em geral e em Linux em particular. No Brasil, tudo o que tinhamos eram revistas como a Info (fundamentalmente comercial) e a também saudosa Geek (que publicou o primeiro CD de distribuição Linux em bancas de jornal, no caso do Conectiva Marumbi).
Quando a Revista do Linux surgiu, tudo era muito mais difícil do que hoje em dia: as configurações para coisas muito simples (como conexão com a Internet) eram um parto. Vira e mexe era necessário compilar o Kernel para fazer a placa de som funcionar (coisa rara atualmente, exceto nos casos mais drásticos). LiveCDs? O que era isso?
Nesse ambiente, a Revista do Linux era a ponta de lança que oferecia aos leitores dicas e suporte, em uma época em que, muitas vezes, horas e horas de pesquisa e dedicação eram necessários para colocar seu sistema funcionando com Linux. Um tempo muito, muito antes de Ubuntu, Knoppix, Kurumin e outros LiveCDs, antes dos instaladores gráficos, antes dos sistemas de autodetecção de hardware. As dicas e reportagens publicadas pela revista do Linux (que você ainda pode ver na Net, graças aos mirrors feitos antes do fechamento definitivo da Revista) eram (e ainda são) extremamente úteis, ajudando no suporte a algo que, na época, era um desafio: instalar uma estação ou servidor Linux funcional.
Agora, além disso, o Rodrigo Stulzer conseguiu, com a ajuda do Alex Lutkus, publicar as imagens originais das capas da Revista do Linux. Acho que, acima de tudo, é melhor deixar o próprio Rodrigo Stulzer falar:

As Capas Originais das Primeiras Edições da Revista do Linux | Empirical Empire

A Revista do Linux, editada pela Conectiva, foi a primeira revista especializada em Linux e Softwares de Código livre e aberto do Brasil; quem sabe até da América Latina. Ela teve o seu primeiro número publicado em dezembro de 1999 e encerrou suas atividades com o número 50, no ano de 2004.

Revista do Linux

Foi muito interessante criar uma revista do zero. Fizemos história na época. Mas a queda do mercado editorial forçou o seu cancelamento prematuro.
Os primeiros 19 números da revista foram ilustradas pelo Alex Lutkus, que por sinal também ilustrou o último livro do Aurélio. Além disso ele teve até ilustrações premiadas e usadas pela Nasa/ESA!
O Alex acabou se tornando um grande amigo. Atualmente trocamos emails diariamente e falamos sobre inúmeros temas, desde desenho, livros, astronomia, música, histórias em quadrinhos e tantas outras coisas mais. Até vou publicar aqui algumas das conversas que tivemos. Acho que você irá gostar!
Numa destas conversas resolvemos resgatar as capas originais das primeiras edições da Revista do Linux. Capas limpas, sem títulos, chamadas ou qualquer outra coisa. Somente as ilustrações do Alex, em alta definição. Elas são ótimas para quem conheceu as capas na época, revendo-as agora mais puras.

As capas originais estão no site do Rodrigo em alta resolução.

Powered by ScribeFire.