andrelop’s blog

Debian Maintainers : sua chance de contribuir sem precisar passar por burocracia

Abaixo estou reproduzindo a mensagem que acabou de ser enviada para a lista de discussão debian-devel-annouce@lists.debian.org sobre a abertura, ainda em caráter beta, do programa de Mantenedores Debian.

Trata-se de uma ótima oportunidade para quem tem vontade de contribuir mas não deseja se ligar oficialmente ao projeto passando por todo o processo para se tornar um desenvolvedor Debian. Espero que gostem :

No início de Agosto, o projeto Debian votou o endorsamento do conceito de “Mantenedores Debian”, o qual permitiria a contribuidores que, apesar de não serem desenvolvedores Debian completos, tivessem o direito de manter seus próprios pacotes no repositório de pacotes Debian sem que fosse necessário um padrinho para cada upload[0].

Desde então, um sistema para manter um chaveiro separado para mantenedores Debian foi implementado[1], junto com mudanças no software que controla os repositórios para suportar uploads restritos assinados por essas chaves[2]. Agradecimentos em particular a Cameron Dale, Miriam Ruiz e Fathi Boudra por servirem de cobaia durante a implementação inicial e durante os testes.

Agora estamos prontos para aceitar um número de candidatos limitado e, devido a isso, estamos entrando em uma fase beta. Isso significa que achamos que temos tudo pronto e funcionando a contento, mas que provavelmente esquecemos algumas coisas e, até que saibamos quais são essas coisas e as corrijamos, nós iremos confiar nos Mantenedores Debian (DM) para nos ajudar a nos certificar que o sistema esteja sendo executado da forma mais suave possível, conforme ele foi planejado.

Caso você seja um não Desenvolvedor Debian que já mantenha softwares dentro do Debian através de um padrinho e tenha um bom conhecimento sobre como trabalhar no Debian, uma chave GPG assinada por alguns Desenvolvedores Debian (DD) e um registro de de bom trabalho comprovado, então você é o tipo de candidato que estamos procurando para nos auxiliar a finalizar os testes. Caso aceito, você será capaz de fazer upload de seus próprios pacotes diretamente sem incomodar seu padrinho.

Para se candidatar, fale com seu padrinho, com seu gerente de aplicação (AM) ou com qualquer outro DD que você conheça e com o qual você trabalhe para verificar se você está pronto para dar esse passo - você precisará que os mesmos escrevam uma mensagem para a lista de discussão debian-newmaint sobre o que você já fez que possa fazê-los pensar que você é um bom mantenedor.

Caso você seja um DD que conhece um não-DD o qual você ache que faria bom uso dos privilégios extras dados a um DM, você talvez queira conversar com ele/ela e encorajá-lo/encorajá-la a se candidatar.

Candidaturas são feitas cadastrando-se um bug no pacote Debian de nome debian-maintainers - por favor, consulte o arquivo README desse pacote para maiores instruções sobre qual informação é necessária e como coletá-la.

Note que, uma vez que você seja aceito como um DM, você ainda só poderá fazer uploads de pacotes que já estejam presentes na suíte unstable dos repositórios Debian com seu nome e endereço de e-mail nos campos Maintainer: ou Uploaders: e que possuam a campo “Dm-Upload-Allowed: yes” definido. Isso significa que você precisará que seu padrinho faça ao menos um upload com a campo Dm-Upload-Allowed definido.

Caso você tenha dúvidas, comentários ou sugestões você pode entrar em contato com a equipe DM no endereço d-m-team@lists.alioth.debian.org (em inglês somente).

Assinado,
Equipe do chaveiro DM,
Joey Hess
Anibal Monsalve Salazar
Anthony Towns

[0] http://www.debian.org/vote/2007/vote_003

Existem deliberadamente uma porção de diferenças entre a proposta
e o que está implementado no momento. As diferenças são :

- A adição de Anibal a equipe do chaveiro (aprovado pelo DPL)

- o chaveiro é mantido usando git ao invés de SVN, em
git://git.debian.org/git/d-m/debian-maintainers.git

- o campo Changed-By: do arquivo .changes é consultado em adição
ao campo Maintainer: para determinar se um upload é patrocinado

- o campo Dm-Upload-Allowed e os campos Maintainer/Uploaders
da última versão do pacote incluído na suíte alvo são usados para
restringir uploads de DM ao invés da última versão enviada via upload
para a suíte unstable (isto principalmente tem efeito para uploads para
proposed-updates e nos casos de mais de um upload entre pulsos)

[1] Consulte o pacote debian-maintainers na unstable
[2] http://lists.debian.org/debian-dak/2007/10/msg00009.html

É isso aí. Para quem estiver interessado, mãos na massa !

SSD : a solução para o gargalo atual em nossos sistemas ?

As indicações estão em todos os lugares : primeiro nos players portáteis e telefones de luxo que andam aparecendo aos montes e, ultimamente, com a indicação de grandes nomes do mercado, como a Apple, que, segundo as notícias que circulam por aí, vai lançar um ultra-portátil que utilizará tecnologia SSD, em seu evento anual MacWorld Expo and Conference, por volta de janeiro do próximo ano.

O Slashdot nos informou hoje que já existem empresas que estão produzindo discos de estado sólido que ultrapassam a capacidade de armazenamento de 1TB.

Nada mal para nossos padrões de uso doméstico atuais, concorda ? Eu mesmo possuo um disco SATA II de 250GB em meu desktop doméstico que ainda anda pouco utilizado, mas isso é só devido a minha conexão Internet, a qual não pode ser considerada como uma conexão de banda larga. No máximo, um conexão de banda-sofrivelmente-quase-larga.

De qualquer forma, com o aumento das ofertas de opções de acesso a Internet em conexões banda larga, o aumento da oferta de soluções que nos permita armazenar uma maior quantidade de informações também tende a aumentar. Anteriormente, nos contentávamos em armazenar nossos e-mails, documentos e arquivos que, na maioria das vezes, se tratavam de dados em texto puro ou em algum formato parecido, que não demandava tanto espaço em disco.

Hoje em dia, é extremamente comum encontrarmos colegas que possuem dezenas ou até mesmo centenas de gigabytes de arquivos de música ou vídeo digitais (nem sempre conseguidos de forma legal, mas isso é outra história). Cada vez mais precisamos de mais espaço para armazenar nossas preciosas coleções virtuais/digitais de arte e conhecimento que tanto prezamos e que tanto insistem em lotar nossos discos.

O problema é que, aparentemente, a tecnologia utiilizada nos discos rígidos, conforme a conhecemos atualmente, parece não ter evoluído tanto quanto outras tecnologias irmãs (como processadores e memórias) tem evoluído nos últimos tempos. O post do kernel hacker Robert Love sobre o assunto, sindicalizado no Kernel Planet, exemplifica bem o problema que estamos enfrentando atualmente.

Segundo ele, desde que compilou seu primeiro kernel (versão 1.1 ou 1.2), a velocidade de transferência de dados em sua conexão Internet já aumentou 11.500 vezes se comparada ao modem 2400 que ele utilizava na época, a velocidade de acesso a memória aumentou 2.000 vezes e a disponibilidade de espaço em disco aumentou 3.000 vezes.

Porém, a velocidade de acesso a dados em discos rígidos ainda continua essencialmente a mesma. Ele ainda aponta como fonte sua palestra na GUADEC de 2005, onde ele diz que acesso a disco é 25.000 vezes mais lento do que o acesso a um registrador de propósito geral e termina dando a entender que as coisas não estão evoluíndo de acordo na indústria de armazenamento doméstico.

Segundo a definição na Wikipedia, o acesso a discos que utilizam a tecnologia SSD é mais do que 250 vezes mais rápido do que os discos rígidos mais rápidos da época em que a entrada na Wikipedia foi escrita, em 2004. E, de lá para cá, aparentemente, não tivemos mudanças sensíveis na tecnologia de discos rígidos que fizessem com que essa diferença caísse drasticamente, infelizmente.

As principais razões (existem outras) que ainda impedem que computadores oferecidos ao mercado doméstico sejam equipados com discos que utilizam a tecnologia SSD são o preço elevado (também segundo a mesma definição na Wikipedia citada acima, perto de US$ 8 por GB em discos SSD comparados a US$ 0.25 por GB nos discos mecânicos atuais) e o fato de discos SSD terem uma expectativa de vida bem menor do que os discos rígidos atuais, já que os discos SSD possuem uma quantidade máxima de operações de gravação limitadas se comparadas a discos rígidos usuais.

De qualquer forma, existem sistemas de arquivos especiais para discos SSD (como os sistemas de arquivos JFFS e JFSS2, no caso de kernels Linux) que diminuem um pouco esse problema, sendo mais inteligentes na forma que gravam os dados em disco e diminuindo a frequência das gravações para evitar o desgaste além do necessário.

A notícia que saiu no Slashdot hoje, citado no início deste post, também informa que um dos modelos de discos SSD oferecidos por um dos fabricantes citados suporta taxas de transferência de 4Gbps. Um dos discos em questão suporta 55.000 operações de I/O por segundo e atinge uma taxa de transferência de dados sustentada de 230MB por segundo. Em comparação, um disco rígido rápido atual atinge por volta de somente 300 operações de I/O por segundo.

Parece que, assim que os preços de soluções baseadas em SSD começarem a diminuir um pouco mais (obrigado Apple por estar popularizando essa tecnologia com o uso da mesma nos novos IPod e em seu iPhone), teremos encontrado nosso sucessor dos discos rígidos mecânicos atuais.

Gerenciamento de atualizações : uma solução simples e eficaz

Para aqueles, como eu, que precisam administrar dezenas de servidores e mantê-los atualizados em relação a aplicação de atualizações de segurança, a forma mais fácil de cumprir essa tarefa seria automatizá-la ao máximo.

Porém, quando o assunto é aplicação 100% automatizada de novas versões de pacotes de softwares em servidores de produção sem intervenção humana alguma, eu tendo a ter um nível de aceitação bastante baixo para essa idéia, por razões óbvias.

A solução, em meu caso, foi adotar uma solução que automatiza parcialmente o processo de gerenciamento de atualizações. A parte que exige mais participação intelectual, ou seja, a aplicação das atualizações propriamente ditas, eu mesmo prefiro executar manualmente, visto que posso interferir caso qualquer problema maior ocorra.

Como utilizo Debian GNU/Linux na imensa maioria dos servidores que administro, as tarefas de checar pela disponibilidade de atualizações e fazer o download das mesmas são triviais, já que existe suporte para fazê-las de forma bastante simples nas ferramentas de gerenciamento de pacotes nativas do próprio sistema operacional.

Porém, mesmo com a simplicidade e facilidade fornecida por essas ferramentas, quando a quantidade de servidores a ser administrada cresce a tarefa de ter que checar pela disponibilidade das atualizações, verificar a aplicabilidade de cada uma delas a cada um dos servidores administrados e fazer o download das mesmas, deixando as atualizações guardadas em um cache local para posterior aplicação, é algo que começa a consumir um tempo bastante grande.

Para facilitar, adotei já há alguns anos uma solução de gerenciamento de atualizações (que pode ser configurada para aplicar automaticamente as atualizações de maneira relativamente simples, mas não pretendo usar essa funcionalidade) bastante simples que cumpre essas tarefas de forma bastante satisfatória.

Trata-se do apticron, um script shell bem simples e disponível como um pacote Debian nos repositórios oficiais de pacotes Debian. Instalá-lo é tão simples quanto instalar qualquer outro pacote Debian comum, ou seja, ele se encontra somente a um aptitude install de distância

Após instalá-lo, costumo modificar somente duas variáveis no arquivo de configuração /etc/apticron/apticron.conf : a variável de nome EMAIL e a variável de nome LISTCHANGES_PROFILE.

Para a primeira variável, forneço como valor o endereço de e-mail no qual eu desejo receber as mensagens de aviso que serão enviadas pelo apticron quando novas atualizações estiverem disponíveis e, no caso da segunda, simplesmente descomento a linha que define a variável, deixando a mesma com o valor apticron.

Isso faz com que, ao enviar as mensagens de aviso de atualizações aplicáveis aos seus servidores, o apticron obtenha a saída do utilitário apt-listchanges (mais um utilitário interessante disponível também como um pacote Debian nos repositórios oficiais Debian e também somente a um aptitude install de distância) e a envie juntamente as mensagens de aviso, o que lhe permite conhecer, além dos pacotes e versões novas disponíveis para instalação, a lista de mudanças (o changelog) dos pacotes para os quais existam atualizações disponíveis.

Além de lhe avisar sobre as atualizações disponíveis e aplicáveis aos seus servidores, o apticron, por padrão, já faz o download das mesmas e as deixa no cache local de pacotes de seu gerenciador de pacotes, de forma que, posteriormente, você precise somente se conectar ao servidor analisado pelo apticron e executar o comando a seguir :


# aptitude upgrade


Pronto. As atualizações deixadas em seu cache local de pacotes serão utilizadas e aplicadas em seu servidor, da mesma forma como você costuma atualizar seus pacotes Debian em um processo usual, sem o envolvimento de nenhuma ferramenta de gerenciamento de atualizações como o apticron.

A execução do apticron ocorre diariamente (por padrão, mas isso pode ser modificado conforme sua necessidade) junto a execução das tarefas agendadas para execução com periodicidade diária pelo cron, sob o diretório /etc/cron.daily (mais especificamente, no arquivo /etc/cron.daily/apticron).

Como se trata de um script shell simples (em /usr/sbin/apticron), o apticron pode ser modificado facilmente, inclusive para que as atualizações já sejam aplicadas automaticamente após o donwload das mesmas, caso desejado.

Novamente, isso não seria algo que eu recomendaria, visto que existem diversos detalhes a serem observados durante uma atualização e decisões que precisam ser tomadas por um intelecto humano (e não por um script shell simples), as quais, nem sempre, possuem uma resposta padrão válida para todos os casos.

De qualquer forma, acredito que o apticron cumpre realmente as tarefas que se propõe a cumprir, de forma simples e descomplicada. Para outras necessidades mais exóticas, uma possibilidade seria utilizar o cron-apt.

Pessoalmente, posso dizer que já utilizei o cron-apt e acabei optando pelo apticron por esse último ser mais simples, cumprir somente as tarefas que eu realmente precisaria automatizar (sem mais nem menos) e funcionar de forma mais confiável que o cron-apt em meus testes.

Por último, apesar de ser evidente para os leitores que chegaram até aqui, esta é uma solução específica para distribuições GNU/Linux baseadas em pacotes Debian. Qual a solução que vocês utilizam para seus servidores, sejam eles baseados em um sistema de gerenciamento de pacotes Debian ou não ? Deixe suas dicas, experiências e indicações nos comentários.

Masoquismo virtual 102 : configurando um MX secundário (the easy way)

Eu não me canso de ficar espantando com a facilidade de se fazer as coisas com o Postfix se comparando a outras soluções de MTA, sejam elas proprietárias ou livres.

Hoje precisei configurá-lo para que meu servidor de mensagens pudesse temporariamente atuar como MX secundário para alguns domínios de um amigo, de modo que os mesmos não ficassem completamente invisíveis para todo o mundo durante a movimentação de um servidor para outro.

Minha tarefa foi somente fazer a porção que me cabia como administrador do servidor que atuaria como MX secundário e não também configurar o servidor que já atua como MX primário. Para minha surpresa, foi algo extremamente simples de ser feito usando Postfix, como eu já esperava, dadas as minhas experiências anteriores felizes lidando com o mesmo.

Eu simplesmente tive que incluir os domínios em questão no parâmetro relay_domains e me certificar de que o parâmetro smtpd_recipient_restrictions tivesse uma restrição que checasse os domínios anteriormente listados no parâmetro relay_domains. Para isso, a documentação do Postfix indica o uso da restrição check_relay_domains, mas essa restrição ficou obsoleta e foi substituída pela restrição reject_unauth_destination já há alguns anos.

No final, as linhas inseridas/modificadas no arquivo de configuração principal do Postfix (arquivo /etc/postfix/main.cf em meu caso) foram as seguintes :


relay_domains = $mydestination, dominioadicional1.com, dominioadicional2.com, dominioadicional3.com

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_policy_service inet:127.0.0.1:60000, reject_unauth_destination


Para essa tarefa, a única restrição realmente importante a ser inserida no parâmetro smtpd_recipient_restrictions é a restrição reject_unauth_destination. As outras restrições presentes cumprem outras tarefas que não vem ao caso no momento e não são assunto para este post (quem sabe um post futuro).

Isso já foi o bastante para que meu servidor passasse a receber as mensagens destinadas aos domínios adicionais e enfileirá-las localmente, de forma que as mesmas ficassem armazenadas temporariamente até que o servidor MX primário voltasse a ficar operacional posteriormente.

Mas o leitor esperto irá notar que, somente com essa configuração, estamos recebendo toda e qualquer mensagem destinada aos domínios adicionais em questão. Lógico, meu antispam e minha solução de greylisting vão cuidar da maioria da porcaria virtual, mas seria importante receber e manter as mensagens somente para os endereços reais dos domínios adicionais e não para qualquer coisa que termine com os domínios em questão como endereço.

Para isso, simplesmente utilize o parâmetro relay_recipient_maps e aponte para um mapa de lookup do Postfix que contenha os endereços os quais você saiba que são endereços realmente válidos. Um exemplo de configuração desse parâmetro seria, no arquivo de configuração principal do Postfix, o seguinte :


relay_recipients_maps = hash:/etc/postfix/relay_recipients


O próximo passo é criar o arquivo apontado pelo parâmetro relay_recipients_maps, ou seja, no caso, o arquivo /etc/postfix/relay_recipients. Esse arquivo irá conter os endereços válidos dos domínios adicionais da seguinte forma :


usuario1@dominioadicional1.com OK
usuario2@dominioadicional1.com OK
usuario1@dominioadicional2.com OK
usuario2@dominioadicional2.com OK
usuario1@dominioadicional3.com OK
usuario2@dominioadicional3.com OK


Para finalizar, criamos o arquivo /etc/postfix/relay_recipients.db usando o comando o comando postmap e forçamos a releitura do arquivo de configuração principal do Postfix recém modificado, usando os comandos a seguir :


# postmap /etc/postfix/relay_recipients
# postfix reload


Pronto. A partir de agora, quando o servidor de mensagens que atua como MX primário dos domínios adicionais em questão for colocado fora de funcionamento temporariamente, as mensagens que antes seriam entregues ao mesmo serão recebidas por meu servidor, enfileiradas temporariamente no disco local e entregues de volta ao servidor que atua como MX primário quando este voltar a operar novamente.

Com a vantagem de que mensagens destinadas a endereços inválidos ou inexistentes destes domínios adicionais serão rejeitadas por meu servidor atuando como MX secundário, o que evitará que tais mensagens ocupem recursos do servidor (como espaço em disco, por exemplo) para depois serem sumariamente apagadas quando forem repassadas ao MX primário.

Leopard vs Java : o perigo de se espalhar informações incorretas

Estive lendo algumas notícias e me deparei com um post que critica o fato da Apple não ter incluído suporte a Java em sua nova versão do Mac OSX, a versão 10.5, também conhecida pelo codinome de Leopard. Tico e teco se bateram por um milésimo de segundo e logo pensei : Opa, perái! Não existe nada de fato nessa história toda.

O fato real é que a Apple não inseriu suporte a Java 1.6 no Leopard, mas o suporte a Java 1.5 está incluso. E algumas pessoas inclusive acreditam realmente que o suporte incluso foi um avanço se comparado ao suporte anteriormente existente na versão anterior do Mac OSX, a versão 10.4, codinome Tiger.

E isso me custou apenas dois minutos de pesquisas no grande oráculo pai dos burros e a leitura dos primeiros comentários do post em questão já demonstraram que, hoje em dia, postar algo para conseguir audiência sem checar os fatos realmente não é lá uma boa estratégia. Seus leitores rapidamente vão desbancar qualquer fato incorreto em seus textos, tenha certeza.

Os desenvolvedores Java podem sim estar descontentes com a Apple devido a mesma não ter incluído suporte para o que há de mais atual relacionado a tecnologia Java na última versão de seu sistema operacional, mas daí a dizer que nenhum suporte a Java foi incluído é um estrada com centenas de milhares de quilômetros de distância.

O artigo em questão inclusive diz que seria bom se a Apple mudasse sua atitude e suas relações com a comunidade de desenvolvedores e incluísse suporte oficialmente a outras linguagens além de sua preferida, Objective-C. O que o autor do post não percebeu é que, além de ter errado no caso do Java, ele errou feio nesse caso também.

Novamente, dois minutos de pesquisa nos leva a suscinta (mas informativa o bastante para nossos propósitos) seção sobre tecnologias Unix existentes por baixo da interface polida do Leopard. Lá, podemos conferir que, iniciando com o Leopard, existe agora suporte oficial, fornecido junto ao sistema operacional, para linguagens de script como Ruby e Python, inclusive com suporte específico nas ferramentas de desenvolvilmento da Apple, como o Xcode, por exemplo.

Não, eu não sou um fanboy da Apple e não, não recebi nenhum pagamento para escrever em defesa da mesma. Longe disso, eu não concordo com um caminhão de coisas que a Apple faz e estou longe de passar a sequer centenas de quilômetros perto da folha de pagamento da Apple, mas eu simplesmente me dei ao trabalho de pesquisar algo em torno de dez minutos antes de escrever esse post e checar alguns fatos antes de escrevê-lo.

Moral da história : cuidado com o que você lê por aí. Cheque os fatos e não saia por aí reproduzindo histórias sem antes checar realmente se elas condizem com a verdade. Você pode estar, menos sem ter a intenção, queimando sua credibilidade junto a seus leitores.

Mais valioso do que dinheiro

Hoje, conferindo os feeds dos sites de notícias que costumo acompanhar, me deparei com um post interessante que apareceu no Liferea, vindo do agregador Planet Debian.

Na verdade, o post em si não é lá muito interessante, mas sim um link para um antigo artigo (datado de 1987) sobre o impacto de recompensas como fontes de motivação, citado no post em questão.

O interessante é que o artigo, mesmo sendo bastante antigo (20 anos), confirma alguns sentimentos que eu tenho sobre essa questão. Não que eu seja anti-capitalista ou que não goste de dinheiro (pelo contrário, vide meu post anterior) mas acredito que compensação financeira nem sempre seja a única ou até mesmo a melhor fonte de geração de incentivos.

Logicamente, um aumento de salário deixa qualquer um contente mas muitas vezes um elogio pode ter um efeito incentivador muito maior do que algumas moedas a mais entrando em seu bolso. Em meu caso, um elogio vindo de pessoas certas então é algo ainda mais incentivador e gratificante. As pessoas certas, em meu caso, são pessoas que, por algum motivo qualquer, eu admiro.

Receber um elogio de um de seus ídolos ou daquela pessoa na qual você sempre se espelhou é um sentimento indescritível e faz muito bem ao ego. Contribuir com um projeto de software livre é algo muito interessante porque lhe permite, com uma dose cavalar de esforços aplicada, experimentar esse tipo de sentimento e, ao mesmo tempo, ser útil para uma população muito maior de indivíduos do que você, seu chefe e seu próprio umbigo.

O artigo em questão também cita que a criatividade e o interesse intrínseco diminuem caso a tarefa a ser cumprida seja feita somente visando um ganho ou retorno específico. Isso eu posso confirmar, com certeza. Se você trabalha em algo somente por estar interessado em quanto aquilo vai lhe render financeiramente, mesmo sendo capaz de produzir algo bom ao final, certamente você não vai produzir algo maior do que isso, algo grande que possa ser notado, lembrado e admirado por muitos, algo do que você realmente se orgulhe.

O sentimento de fazer parte de algo maior (uma comunidade mundial de pessoas unidas por um objetivo em comum no caso do software livre), de poder ser útil para uma grande quantidade de pessoas, de fazer aquilo que você gosta e receber um pagamento muitas vezes ainda mais valioso do que dinheiro por isso é altamente gratificante.

Isso certamente explica o que impulsiona e motiva alguns colaboradores de projetos de software livre a participar de algo que não lhes rende lucro direto, mas que lhes proporciona um sentimento de dever cumprido, de estar fazendo a coisa certa. Algo que muitos não conseguem enxergar, talvez por estarem viciados em ser recompensados através de ganhos financeiros por tudo que fazem e somente serem motivados a percorrer aquela milha a mais caso exista um retorno direto garantido.

Vendendo a alma (ou, opcionalmente, pagando a hospedagem)

Olá pessoal,

Os mais atenciosos (ou qualquer um que leia os posts diretamente no blog e não somente assinando o feed) irão perceber que algumas mudanças ocorreram no blog desde o meu último post.

Mudei novamente o tema utilizado pelo blog. Acho que desta vez encontrei um tema bacana e simples, que não prejudica a leitura dos posts e não deixa uma boa parte dos posts desalinhados e com problemas de exibição em alguns navegadores, como era o caso do tema anterior.

Além da mudança no tema, vocês vão notar que eu passei a usar o AdSense do Google no blog. Não é que eu queira parar de trabalhar e viver somente de renda gerada do AdSense (até porque não tenho calibre para isso), mas uma pequena (e bota pequena nisso, no caso do AdSense) fonte de renda adicional não é nada ruim.

Se eu conseguir pagar as despesas de hospedagem do servidor virtual que hospeda este blog já está valendo, mas se alguns centavos a mais aparecerem, também prometo que não fico chateado Achei que seria importante avisar aos leitores do blog sobre essa minha decisão e deixá-los cientes de que não vendi a alma ao diabo e nem me tornei um porco capitalista, como todo blogueiro que resolve começar a monetizar seu blog parece ser percebido hoje em dia.

Tentei deixar uma quantidade pequena de anúncios e vou me esforçar nos próximos dias para acertar o AdSense no intuito de exibir ao máximo possível somente anúncios relacionados aos temos dos textos sendo escritos no blog, apesar de eu acreditar que isso o AdSense vai aprendendo aos poucos conforme os posts forem aparecendo e ele for compreendendo minha forma de escrever.

O que vocês acharam ? Ficou muito intrusivo ou é suportável ? Deixe suas opiniões sobre esse questão nos comentários. É importante notar que os anúncios sendo exibidos no momento eram os anúncios do menor tamanho existente dentre as escolhas de banners horizontais na lista de banners para uso disponibilizada dentro da interface de administração do AdSense.

Obrigado pela leitura e até o próximo post.

O quê te inspira ?

Você já se imaginou um maratonista que perdeu suas pernas ? Ou um escritor que perdeu seus braços ? Seja lá qual for seu pesadelo infernal, qualquer um de nós teria problemas sérios em cumprir suas funções sem ter os meios indispensáveis para cumprí-las.

O que fazer quando você tem um bloqueio criativo ? E, pior, o que fazer quando um escritor por profissão sofre de um bloqueio desses ? Em um primeiro momento, não parece ser um problema tão grave quanto os problemas citados anteriormente, afinal, você ainda continua com todos os seus membros intactos.

Porém, para aquele que sofre o bloqueio, com certeza, é sim algo comparável ao pior desastre físico possível, visto que as idéias são a fonte de seu trabalho. Sem idéias não se tem sobre o que escrever e, sem que consiga fazê-lo, logicamente, não se consegue trabalhar. Imagine-se impedido de exercer suas funções, não por não estar disposto a fazê-lo, mas sim por algum motivo inexplicável que o impede. Nada físico, nenhuma pessoa, objeto ou nada parecido. Simplesmente não vai.

Eu posso imaginar a dificuldade que uma pessoa criativa deve enfrentar quando sua fonte de idéias, anteriormente tida como algo inesgotável, de repente, sem explicação aparente, se esgota. Não sou uma pessoa que depende dessa fonte de idéias constantemente em funcionamento perfeito, mas sempre que percebo que a fonte está próxima de se esgotar, fico extremamente chateado.

Constantemente tenho vontade de escrever algo novo, mas não é sempre que tenho a inspiração necessária para fazê-lo. Também não sei dizer ao certo o ponto exato a partir do qual essa inspiração é o bastante para gerar conteúdo decente. As vezes simplesmente acontece, mesmo sem que eu tenha um assunto específico sobre o qual escrever. A coisa flui e no final parece algo interessante o bastante para ser publicado e compartilhado com os leitores.

Porém, é muito mais fácil quando se tem alguma idéia ou algum tema já pensado sobre o qual escrever. Repetir alguns passos que repeti quando tive boas idéias que julgo terem resultado em bons textos por vezes engana o cérebro o bastante para força-lo a acordar, fazendo com que os pensamentos comecem a clarear. O bastante para que algo aproveitável surja.

Mas não é uma fórmula mágica que sempre funciona. Ainda não consegui entender o que exatamente dispara a luz vermelha e exige que o cérebro passe a funcionar da forma que eu gostaria que funcionasse sempre. Uma das coisas que com certeza gera vontade de escrever cada vez mais é o retorno dos leitores sobre os textos que escrevo.

Quando há um grande retorno, sempre existe mais motivação para escrever cada vez mais e sempre algo interessante acaba surgindo. Por outro lado, a falta de retorno, seja através de comentários ou mensagens de aprovação e/ou reprovação, gera uma onda crescente de desinteresse que afasta ainda mais qualquer resquício de boa idéia que poderia estar se formando.

Também é uma situação bem parecida com a história do ovo e da galinha. Sem escrever, não tenho retorno de leitor algum e, sem retorno algum, novas idéias não aparecem e a bola de neve do desinteresse vai se fortificando, ficando maior e mais perigosa. O quê te inspira ? O que faz com que você tenha motivação para produzir algo que julgue interessante o bastante a ponto de expor ao mundo ? O que te move, te motiva, te inspira e faz com que a barreira da vergonha seja ultrapassada, te permitindo compartilhar suas ideias e visões com seus semelhantes ?

A anonimato parcial que a Internet proporciona pode ser o combustível que faltava para fazer com que um escritor solitário, que geralmente coloca suas idéias em um papel para sua própria apreciação, torne suas idéias públicas. Eu acredito que isso seja o caso de vários blogueiros desconhecidos que podem, de um dia para o outro, atrair meia dúzia de leitores admiradores de seus textos.

Mas não é exatamente a isso que eu me refiro. Não é sobre o que te faz dar o primeiro passo e começar a expor suas idéias, mas sim o que te mantém no mesmo caminho ao longo do tempo, com todos os empecilhos encontrados pelo meio do caminho em sua rotina complicada de trabalhador e blogueiro em tempo livre ?