Pages

Thursday, December 31, 2009

Feliz Ano Novo !!!

Um novo ano chega em algumas horas. Normalmente eu busco inspiração para escrever nesse último tópico do ano, ano passado a inspiração foi zero, esse ano também...

Então eu, novamente, peço desculpas, mas vou plagiar a mim mesmo com uma adaptação da mensagem de 2008 e do ano passado.

Que 2010 seja mais um ano onde cada um possa superar e aprender com as dificuldades para que todos possamos nos tornar pessoas melhores, e dessa forma, melhorar o ambiente onde vivemos como um todo. Um abraço e um bom 2010 para todos !
A mensagem pode ser uma simples cópia, mas novamente os votos são sinceros.

Um abraço e que tenhamos todos um 2010 bem proveitoso.

Tuesday, December 29, 2009

Para um 2010 ainda melhor ...

No final de novembro de 2008 eu escrevi um tópico sobre planejamento financeiro. Com o final de 2009, não custa lembrar de realizar seu planejamento financeiro novamente esse ano ...
Nada mudou de lá para cá. O texto continua atual. E posso continuar afirmando que esse planejamento foi muito importante para mim durante esse ano que passou.

Sunday, December 27, 2009

Ordem na vida digital: Os arquivos do computador

A organização da estrutura de diretórios é um dos temas mais polêmicos que existe. Muito dessa polêmica está relacionada com o fato de que cada um faz o que é melhor para si e em geral mudar pode consumir mais energia do que será economizado após a mudança (e isso acontece com muita freqüência).

Antes de mais nada, leia esse texto do Efetividade. O que vou escrever aqui pode ser considerado uma forma de responder a essa pergunta.

Embora eu não seja tão pretensioso para acreditar possuir a resposta completa para a pergunta, existem três pontos que podem ser considerados padrão para o bom convívio com os seus arquivos:
  1. Separe o pessoal do profissional.
  2. Tenha uma caixa de entrada, um diretório onde ficam os arquivos que estão entrando no computador e esvazie-a com freqüência satisfatória.
  3. Se for usar data no nome do arquivo ou diretório, inverta a ordem natural dessa informação, ou seja, no lugar de 25-12-2009, anote 2009-12-25, isso permite que a organização por nome seja compatível com o tempo.
É comum as pessoas mais envolvidas como uso frequente do computador repeitar instintivamente as duas primeiras regras.
Minha estrutura de arquivos consiste em 5 diretórios de dados no $HOME.
  • e-Library - onde ficam todos os meu documentos arquivados, inclusive artigos de internet que imprimi para pdf. É a fonte de informação de referência do meu computador.
  • Entretenimento - onde estão os podcasts, fotos, imagens divertidas, piadas, todos aqueles pps que não joguei fora, vídeos baixados do youtube (porque eu não confio tanto assim no youtube). Registro da minha coleção de DVDs e cópia digital dos meus CDs de música e um diretório para as músicas que eu vou ouvir (e sim, eu separo mesmo, o primeiro é simples backup). Resumindo, é onde o computador é a central de entretenimento.
  • InOutBox - É onde está a zona. O que entra 0u sai do meu computador passa por esse diretório.
  • Profissional - Apenas material profissional.
  • System - Arquivos de backup de configurações. Não é o backup dos dados, apenas das configurações. Por exemplo, antes de instalar uma nova extensão eu faço um backup do diretório .mozilla. E guardo aqui. Se algo der errado é só restaurar. Backups verdadeiros somente são backups se não estiverem no mesmo HD.
Além desses diretórios, devo incluir um diretório chamado pessoal, que está montado dentro de um sistema encriptado (da forma quase exata da explicação que está no link). Dentro desse diretório, além de comprovantes de transação bancária, IR, etc, estão o .mozilla e todos os demais arquivos de configuração que possuem dados pessoais. E assim como está na dica - foi de lá que tive a idéia - uso links simbólicos para colocar os diretórios de configuração no devido lugar.

Mas como organizar cada diretório ?

O InOutBox é onde fica a zona. Tento mantê-lo vazio, mas é quase impossível. Então o básico de sua divisão interna é "softwares", "print", "documentos" e "downloads". Mas aqui a regra é fraca. Apenas tento gravar os arquivos ali de forma que minimize o eventual arquivamento do mesmo, Entretanto, muito do que está nele é temporário, sendo deletado em pouco tempo.

O diretório de entretenimento é divido por tópico. Fotos, imagens, vídeos, podcasts, pps, etc. Também é de organização fácil, pois o Amarok e o digiKam cuidam de quase tudo e o que eles não cuidam é muito pouco. E para constar, eu sempre utilizei esses programas, mesmo quando usava o GNOME. O diretório System também segue a mesma regra, mas uso o gerenciador de arquivos para gerenciar os detalhes. Pode até ser que o tamanho desse diretório seja grande, mas o número de arquivos raramente chega a vinte, logo, é de fácil gerenciamento.

O diretório pessoal, a parte de dados pessoais (lembre-se que também há algumas configurações de programas nesse diretório), utiliza dois métodos, usa diretórios que definem o campo assunto/categoria do arquivo e diretórios nomeados por ano-mês (em casos muito particulares, ano-mês-data). Oras, eu não duplico os dados, eu uso atalhos simbólicos. Simples assim. O arquivo do imposto de renda do ano de 2008 fica no diretório IR e um alias para esse mesmo arquivo é criado no diretório "2008", mantendo o arquivo que se chama 2008-ImpostoDeRenda.zip organizado das formas possíveis. O gerenciamento por duas frentes torna tudo muito eficiente, mas é muito mais trabalhoso. Somente vale apena por ser um diretório crítico da minha vida pessoal. Note também que eu escolhi um exemplo fácil.

O e-Library é o maior diretório do meu computador. Nele, eu organizo os arquivos como se estivessem dispostos em tags, onde existem n diretórios que são "as tags". O arquivo está presente em todos eles através de atalhos simbólicos. É uma variação, menos trabalhosa, do gerenciamento do diretório de dados pessoais. Resolve problemas como: o arquivo digital "Comparação entre o GNOME e KDE.ps" fica no diretório KDE ou GNOME ? Eu coloco nos dois diretórios e não terei dúvidas quando for procurar pelo arquivo (ok, esse exemplo é bobo, mas há casos mais críticos). Subdiretórios também são utilizados. No exemplo mencionado, os diretórios KDE e GNOME estão no mesmo nível em "./Linux/Interfaces Gráficas/".

O diretório Profissional é estruturado por projetos. Projeto A, B ou C. Se o projeto A e B compartilham algumas informações em comum, elas são duplicadas. Também há diretórios não vinculados a projetos, tipo: referências, arquivo, administrativo, etc.

Mas o detalhe dessa estrutura que chama atenção é a duplicidade da informação. O motivo é simples. Quando eu arquivar o projeto A, o B pode ainda ter alguma atividade. Diretórios comuns, como referências, nunca vão ser arquivados, vão apenas crescer.

Se houver algum problema de espaço ao duplicar o arquivo, posso utilizar atalhos simbólicos, mas isso ainda não foi necessário.

Quanto ao nome dos arquivos...

Prega-se que o nome de arquivos e diretórios devem seguir um de duas regras:
  1. letras minúsculas, espaços substituídos por "_", sem caracteres especiais, acentos ou qualquer outra coisa que não seja números e letras e os caracteres "-" e "_" ; exemplo: meu_arquivo_sobre_cachaca.ps
  2. estilo wiki, onde o nome do arquivos é escrito sem espaços ou caracteres "-" e "_", e são utilizados letras maiúsculas para iniciar cada palavra do arquivo; exemplo: MeuArquivoSobreCachaca.ps
O meu estilo: Eu uso tudo que o GNU/Linux pode oferecer, de acentos e espaço a caracteres como o "$" e "&". Esteja avisado que isso não é um bom conselho. Na verdade é o pior conselho possível, porque você DEVE saber quando NÃO PODE usar esse conselho. Em outras palavras, deve saber quando esse conselho é um conselho que pode prejudicar o funcionamento do seu sistema (ou, pelo menos, de um programa em especial). Você somente pode fazer o que eu faço, se souber muito bem o que está fazendo e estiver preparado para sofrer eventuais conseqüências (e se for um pouco maluco também).

Eu também não me preocupo com o tamanho do nome. Uso o tamanho que for necessário. Quando usa-se o locate verifica-se melhor resultado se o nome do arquivo for o que tiver que ser. Isso também não é um bom conselho. Especialmente se quiser gravar em um CD/DVD ou mesmo em uma partição fat32 (para esses casos ainda é possível contornar o problema criando um arquivo compactado com um nome curto)

Backup

Todo bom geek faz backup. Se for tão paranóico quanto eu, fará um backup em cada lugar que couber e puder. Do diretório 'Profissional' eu tenho 5 backups (5 HDs diferentes, ei... eu conto com espaço para tal na universidade !!! Não sei se seria tão paranóico se não tivesse). Eram para ser 7, mas dois deram problemas. Já houve uma época que eu tive 3 backups e os 3 deram problemas no mesmo dia, aí eu subi o número para 7 (e como disse, dois deram problemas e não foram recriados em outro lugar).

Eu também tenho todo esse volume de cópias do volume encriptado onde estão os meu dados pessoais e o mesmo vale para fotografias que eu mesmo tirei.

Quatro desses discos guardam cópias que são atualizadas de forma alternada a cada 1 semana, ou seja, cada disco têm entre 1 mês e 1 semana de segurança. O quinto disco é atualizado por dia. Em todos os casos eu uso o rsync. O agendamento constitui de lembretes por e-mail para que eu ative o script manualmente do rsync. Usar o cron (e outros gerenciadores de tarefas) não deu certo porque eles não previam quando podiam sincronizar os dados e quando isso seria um idéia ruim (porque eu teria que restaurar algum arquivo).

O restante dos dados tenho apenas uma cópia, feita a cada 1 mês ou após uma grande modificação de conteúdo. Também feita com rsync.

E ainda faço uma cópia do sistema a cada 3 meses, essa é feita com o partclone.

Conclusão

Eu uso hoje, uma evolução do que usei em 1997, após eu ter dito meu primeiro problema com o Windows 95. Backups, duplicatas, organização por atalhos simbólicos (sim, no windows também era possível fazer isso, embora com menos eficiência e praticidade), etc. São quase 12 anos, e nesse meio tempo criaram o conceito de tags, GTD, entre outros. Bom, usei esses conceitos para melhorar o que já tinha e corrigir o que tive de problemas. Doze anos de uso ajudam muito na maturidade de um método. Pelo menos na hora de identificar os pontos fracos.
  1. O volume de dados cresce exponencialmente com o tempo. Tentar projetar o futuro da melhor maneira possível resolve muitos problemas. Eu também gostaria que meu dinheiro para comprar HDs para backup também acompanhasse essa regra.
  2. Quanto mais tempo levar para esvaziar sua Inbox, pior será na hora de organizar os arquivos.
  3. Gravar em CD/DVD me fez perder muito dinheiro. Eu perdi mais de 300 CDs/DVDs por causa de problemas na mídia ou porque o backup incremental não fazia mais sentido e eu tinha que grava tudo de novo. Hoje é possível utilizar HDs. Uso DVD-RW como "disquete" moderno. E somente penso em ver a utilidade dessa idéia novamente quanto o Blu-ray de 50 GiB estiver por 5 reais na loja da esquina. Caso não sabia, em teoria, o Blu-ray tem proteção contra arranhões. Eu não sei o que isso significa, mas soa muito bem no papel. Seja como for, uma estrutura de backup não fica muito boa e confiável em DVDs. Se isso é fundamental, tenha mais de uma cópia guardada em lugares diferentes.
No fundo, o que eu faço é organizar a informação no computador com o mesmo método que os dados são organizados na minha mente. A palavra chave que te faz lembrar do assunto que deseja, deve te fazer chegar rapidamente no lugar onde o(s) arquivo(s) relacionado(s) a esse assunto está. Dessa forma, o trabalho para localizar um arquivo ou descobrir se existe informações sobre um certo assunto é mínimo. Esse nível de simbiose entre a organização do computador e o usuário somente é conquistada com tempo. E note que sua mente muda, então, seu sistema tem que ser facilmente adaptativo a essa modificação. Embora minha organização seja sólida, ela é flexível, adapta-se facilmente com pouco esforço a minhas necessidades.

Por fim, porém não menos importante, vale lembrar o quanto a informática mudou desde 1997. Naquele tempo, não imaginava-se programas indexadores de conteúdo. Esses programas são excelentes, mas isso não te dá o direito de colocar tudo no mesmo pote sem uma organização qualquer. O indexadores ajudam, mas não devem ser considerados a única forma de gerenciamento de arquivos. Lembrando que existem indexadores gerais, como o Beagle e o Google Desktop, e outros restritos a um certo tipo de arquivo, como o AmaroK (que deve ser o mais famoso, mas não é o único, nem no caso de músicas).

Não menospreze a necessidade de manter os arquivos organizados no seu computador. Se não fizer isso hoje, pagará mais caro amanhã. Lembre-se sempre do que escrevi no início desse texto. Muitas vezes consome-se mais energia mudando a forma que organiza seus arquivos do que se economiza usando o novo sistema organizado. Mas o que eu não disse, é que isso não significa que você estará satisfeito com seu sistema atual de gerenciamento de arquivos, simplesmente significa que não terá tempo ou paciência, etc, para fazer o que gostaria devido a enorme volume de dados que devem ser reclassificados (renomeados, movidos, copiados, etc). Portanto, a dica é nunca se permitir chegar ao ponto de dizer: "eu gostaria de ter um sistema de arquivos e diretórios organizados de forma diferente, mas não tenho disponibilidade para fazer as modificações que desejo".

Thursday, December 24, 2009

Feliz Natal !!!


Noite feliz, noite feliz
Ó senhor, Deus de amor
Pobrezinho nasceu em Belém
Eis na lapa Jesus, nosso bem
Dorme em paz, ó Jesus
Dorme em paz, ó Jesus

Noite feliz, noite feliz
Ó Jesus, Deus da luz
Quão afável é teu coração
Que quiseste nascer nosso irmão
E a nós todos salvar
E a nós todos salvar

Noite feliz, noite feliz
Eis que no ar vem cantar
Aos pastores, seus anjos no céu
Anunciando a chegada de Deus
De Jesus Salvador
De Jesus Salvador

Que uma vez mais esse tempo de renovação nos permita realizar a reflexão necessária para guiar nossas vidas com sabedoria.





Letra copiada da wikipédia e imagens do conjunto de ícones "Smashing Christmas".

Monday, December 21, 2009

Ordem na vida digital: Os feeds RSS

Para colocar ordem na vida digital, um ponto crucial é organizar a sua leitura.
Existem duas formas de acompanhar notícias, blogs e sites: visitando o site ou assinando o site.

Visitar o site significa abrir de tempos em tempos os sites de interesse. Assinar o site significa acompanhar o feed rss que ele oferece.

Esse texto não vai abordar o primeiro caso, mas para não deixar o tema completamente em aberto, saiba que não é algo ultrapassado. Por exemplo, abrir a página principal do site de notícias pode lhe fornecer uma visão mais ampla de todos os destaques que foram publicados do que receber 1000 notícias por dia que você sequer vai dar conta de ler o título. E sim, feeds de notícias podem passar de 1000 tópicos por dia.

Voltando ao assunto principal, como colocar ordem nos feeds rss ? Observe os pontos sugeridos:
  1. Não tenha mais assinaturas do que pode acompanhar.
  2. Não acompanhe o que realmente não interessa.
  3. Duplicidade de informação em diferentes fontes não é algo bom.
  4. Se não consegue se lembrar do nome de todos os sites que você assina, então, divida-os em categorias.
  5. Como você lê ? No computador ou em dispositivos móveis ? Use feeds compatíveis com o método de leitura.
  6. Domine o programa que utiliza para a leitura.
  7. Não assine sites por causa de um único texto interessante.
  8. Agregadores de blogs é uma coisa boa se a grande maioria dos blogs for do seu interesse e possuir conteúdo diversificado e motivador, não violando as 3 primeiras regras.
As três regras de ouro

Eu diria que as três primeiras regras são as máximas do hábito de usar o RSS.

Acredito que todo mundo entenda o motivo de não acompanhar mais sites do que pode ler. O ponto central é que se não pode ler, porque tenta acompanhar ? Você não vai ler, afinal, você não têm tempo para ler.

Da mesma forma, se não gosta do assunto, não quer ler sobre o assunto, não acompanhe. Se eu não me interesso por carros, eu não acompanho nenhum site ou blog de carros. Ponto final.

O terceiro ponto é um pouco mais complicado. A duplicidade da informação, nesse caso, não é plágio. Estamos falando de acompanhar, por exemplo, 20 sites que vão dar a notícia de que o "GNOME pensa em se separar o projeto GNU" (a novela - ou seria teatro ? - está bem explicada no link do BR-Linux.org). Note que eu não menosprezo a importância de uma notícias dessas, faz parte, se quiser acompanhar o tema. O problema é o volume de textos contendo a mesma informação.

É importante ser ponderado, para não ficar míope ao ler apenas de um único lugar. Ler de mais de mais de uma fonte de informação é algo importante. Ajuda na formação pessoal. Mas não deve haver exagero.

Como regra geral, embora MUITO dependente do leitor, pode-se dizer que 5 fontes de notícias por tópico de interesse está de bom tamanho e, em alguns casos, superdimensionado. Para blogs que se destacam pela originalidade, diversidade e ou qualidade, eu não proponho uma regra. Cada um deve sentir quando um certo assunto está cansando.

No meu caso particular, eu posso dar dois exemplos.

Primeiro, quanto a sites de notícias sobre Linux, opensource e tecnologia associada. Eu acompanho dois em inglês, Linux Today e LinuxDevices.com, e um em português, o BR-Linux.org. Tudo que me interessa é publicado no Linux Today e no BR-Linux.org, acompanho o LinuxDevices.com apenas como fonte complementar.

Outro exemplo: leio apenas 4 blogs sobre filmes. E por blogs, entenda, opinião pessoal do camarada que escreve. Esses quatro blogs diversificam o suficiente sobre o assunto para que eu não me interesse por nenhum outro blog - eles resenham quase todos os filmes lançados. Ainda assim, é comum eu ler resenhas em blogs com escopo mais geral que simplesmente colocam ali sua opinião pessoal. Por exemplo, opinião sobre Hancock (a melhor que li sobre esse filme, em minha opinião) ou Avatar, em um blog que não é dedicado a cinema.
É engraçado que muitas vezes, quando os filmes "vazam" dos blogs dedicados para os blogs de escopo pessoal, é quando o filme causa mais impacto, porque são pessoas, e não profissionais, escrevendo.

Se necessário, organize os feeds

Todos os programas decentes de leitura de feeds sabem como criar alguma categoria para o feed. Use esse recursos se necessário.

Eu disse no item 4, se não consegue lembrar de todos os feeds que assina, então, divida-os em categorias. Considere uma "regra geral". Se não sabe quais são seus feeds, você tem muitos. nossa memória seria capaz de guardar uns 20 nomes sites/blogs (sim, caros, podemos até mais...).

Quando o número fica alto, sem categorias para organizar essas assinaturas, você não irá tirar proveito dessas fontes.

Existem duas formas clássicas de organizar os feeds: por freqüência de leitura e por assunto.

Por freqüência de leitura, você criaria as caterorias: TodosOsDias, ACadaDoisDias, UmaVezPorSemana, TodoSabado, ..., etc, ..., QuandoSobrarTempo.

Isso destaca quais as fontes que quer ler sempre das demais. A regra é estabelecer quando a tag/diretório vai ser lido. Nota a categoria QuandoSobrarTempo. Ela pode ser o termômetro para o volume de fontes que vem assinando. Esse método é particularmente útil se você tiver uma quantidade muito grande de fontes ou se tiver uma quantidade grande de fontes que você nem sabe em que categoria colocar.

Por que classificar por categorias por assunto significa separar o que é sobre esporte, filmes, linux, geek, etc.

Mas esses são os métodos clássicos, hoje, eu sugiro a utilização dos dois métodos de forma integrada. Separe os seus feeds por categorias E por freqüência de leitura. Quase todos os programas de leitura de RSS permitem classificar o mesmo feed em duas tags ou diretórios, portanto, faça isso.

Eu sugiro também uma categoria especial: AcabeiDeMeInscrever. Ela separa os feeds recém assinados dos demais. Muito útil para não assinar porcaria.

Organizar os feeds é como organizar as gavetas da mesa. Embora exista regras gerais, como não guardar sorvete na taça dentro da mesa, tudo é muito pessoal. O lápis, o papel, a borracha, etc, fica onde o usuário que utiliza a mesa acha mais conveniente. O importante é saber que não se deve guardar um sorvete dentro da mesa. Se bem que daqui a pouco alguém coloca um freezer dentro da mesa e eu tenho que reconsiderar essa opinião ...

Como você fará a leitura ?

Se vai ler no computador, é provável que queira assinar feeds completos, ou seja, onde a notícia está inteira no seu leitor de feeds e você não precisa ir a fonte original se não quiser, por exemplo, comentar.

Se vai ler em um dispositivo móvel, é provável que queira assinar feeds parciais, onde apenas o início do texto (as vezes apenas o título) é mostrado. Para ler o resto você deve ir ao site original.

Se você vai utilizar os dois métodos, é provável que você tenha uma dúvida cruel que eu não ouso colocar o dedo na resposta... Sim, aqui a coisa fica feia. Se eu disser que tem que usar o feed completo para ter conforto no desktop, você vai dizer que isso vai consumir sua franquia do dispositivo móvel. Se eu disser que deve utilizar o feed parcial, você vai dizer que isso não vai ser muito agradável quando estiver no computador e você vai perder mais tempo que o necessário.

Algumas fontes não lhe dão escolha. As demais ficam por conta de cada um.
Interessante notar que a extensão do firefox "Better GReader" conta um um script Greasemoneky (que eu não vou procurar onde está divulgado) que permite ler o feeds parciais dentro do Google Reader, um leitor on-line de feeds. O que nos leva ao ponto seguinte.

Domine o programa que você utilize

Parece besteira, mas o uso dos recursos que o leitor de feeds te fornece pode ajudar muito no aumento da produtividade de leitura.

Não vou destacar aqui todos os programas que existem... não creio que seja adequado. Fica apenas minha dicas sobre os que eu considero os melhore programas online e para GNU/Linux.
  1. Google Reader - Leitor online do Google.
  2. Bloglines - Clássico leitor do feeds.
  3. Akregator - Programa do KDE.
  4. Liferea - Programa feito em GTK.
  5. RSSOwl - Programa multiplataforma, feito em java.
Dos programas para desktop, meu preferido é o RSSOwl. Entre os online, eu uso o Google Reader, mas muito por um pequeno problema pessoal com o Bloglines.

Por fim...

Os dois últimos pontos da minha lista são mais ou menos triviais. Eu já disse para não misturar as novas assinaturas com as antigas, mas não disse porque. Ainda assim, o motivo pode ser considerado óbvio. É como ver um trailer e achar que o filme é bom. Se o trailer é bom, é provável que o filme não seja ruim, só isso... mas nem isso (nem o inversos) é 100% verdade.

Acredite em mim quando digo que limpar o lixo dos bons feeds não é algo simples. Fica ainda mais complicado quanto mais assinaturas possuir...

Assinar um feed por causa de um único artigo é como gastar 300 reais comprando a caixa de todas as temporadas de "Friends" por causa de um único episódio. Não é nada produtivo.

Também aproveito para fazer um alerta quanto aos agregadores de blogs, chamado de planetas. O cuidado que se teve ter está relacionado aos assinantes. É comum que um mesmo blog esteja em mais de um planeta. Dessa forma, pode ser muito desagradável ler duas, três vezes, a mesma notícia, publicada pelo menos autor, etc. De fato, eu não assumo de que vai ler, propriamente dito, mas se o número de duplicadas for grande, isso é algo chato. Eu lia muitos planetas, hoje leio apenas o Planeta GNU/Linux. O que me interessa de outros planetas eu assina manualmente o blog específico.

Conclusão

Será que ainda é necessário dizer que sendo esse blog, um blog pessoal, toda opinião omitida aqui é fruto da minha experiência acumulada sobre o assunto e não deve ser visto como se essa fosse a única solução ? Gostaria de pensar que não (é meio óbvio, não é ?), mas está dito para não haver qualquer problema.

Eu não consigo imaginar onde esse assunto vai terminar. Muita gente trata o assunto RSS como se fosse algo completamente ultrapassado, mas não é.

Eu não consigo me imaginar sem o RSS. Ele me ajuda nas minhas pesquisas (acadêmicas, pois nunca mais tive problema para me manter atualizado sobre um certo tópico de interesse), filtra o conteúdo que eu desejo, me permite acompanhar o que quero de forma rápida e eficiente, pois eu não perco tempo vendo onde houve atualização e quais foram. O gerenciamento da informação ficou mais fácil, mas simples, mais rápido, mais eficiente, mais organizado, mas dinâmico, definitivamente, melhor. O porém é que a "era da informação" começou ontem !!!

É possível que o conteúdo mude, tenhamos mais áudio e vídeo, quem sabe até, em um futuro muito distante, holografias - salas holográficas - sim, sonhando longe no futuro, muito longe - mas a idéia por traz do RSS permanecerá - uma tecnologia capaz de permitir que o usuário sabia que ocorreu uma atualização no meu site e veja o conteúdo que eu disponho, se assim desejar.

Dessa forma, mesmo que o programa que gerencie as fontes de informação seja completamente diferente dos que existem hoje, a idéia por traz desse gerenciamento não mudará: são as três regras de ouro aqui apresentadas. Seja fiel a elas e não se arrependerá. As demais regras são passionais, alguns podem se adaptar e adorá-las, outros vão refutá-las de imediato. Cada um carrega dentro de si um potencial para se organizar que não deve ser menosprezado ou superestimado.

Saturday, December 19, 2009

Livros inesquecíveis

Recentemente eu dei uma arrumada nos meus livros, então vamos falar sobre livros...

Em meio a eles, acabei observando quais são os livros que eu possuo (e, claro, que eu li) que considero inesquecíveis:
  • Memórias Póstumas de Brás Cubas. Esse livro me ensinou a ver a sociedade. Se eu não me engano, li ele na oitava série. Fiquei fascinado pelo livro. Por muito tempo, eu retive na memória diálogos e passagens inteiras do livro. As obras completas de Machado de Assis podem ser gratuitamente baixadas da internet.
  • Incidente em Antares. O último romance escrito por Érico Veríssimo de quem tenho muito livros. Eu li esse livro devido a minissérie da TV. Eu fiquei revoltado com a adaptação. Foi a primeira vez que tive essa reação. Nem imaginava que tinha sido uma excelente adaptação comparado com o que eu veria depois.
  • Olhai os Lírios do Campo. Outro livro de Érico Veríssimo. Mas esse me marcou porque foi um livro que eu odiei com todas as minhas forças. Sabe quando você lê um livro e não gosta ? Pois é... foi assim. Mas eu não podia largar o livro devido a obrigação escolar de ler ele. É o único dos livros de Érico Veríssimo que eu não gosto.
  • A Bíblia. Você não precisa ser religioso para gostar de um bom livro. E a Bíblia é fascinante. Se eu tivesse 1 trilionésimo do conhecimento passado por ela eu seria uma pessoa bem melhor.
  • As Aventuras de Sherlock Holmes. Eu tenho a coleção completa. Todos os livros e contos publicados por Sir Arthur Conan Doyle. O que dizer ? Se não leu, devia ler. O chato é que depois disso você acha que tudo que você lê e vê por aí não passa de cópia ruim do Sherlock Holmes. Eu já tinha ouvido falar disso, mas depois que li os livros tive certeza.
  • Cassino Royale. Você precisa ler o livro para entender quem era o 007. O personagem do livro é mais sóbrio que o do filme. E o texto de Ian Fleming é genial. Só isso compensa.
  • O Senhor do Anéis. J. R. R. Tolkien é um dos mestres da literatura. Posso não mencionar William Shakespeare e outros mestres nessa minha lista, mas isso é porque é minha lista de livros inesquecíveis e não lista sobre os maiores mestres da literatura. O mais extraordinário sobre esse livro não é o fato de ter lido toda a história em 3 dias sem conseguir parar para fazer outra coisa (nota: a faculdade foi mais fácil que a pós-graduação!). O mais fantástico é que ele criou um novo universo em um nível de detalhe impressionante. A saga é uma saga. É possuí início, meio e fim. E que fim. Não há no meu limitado número livros lidos um história que tenha sido concluída com tanta perfeição, tantos detalhes de sua narrativa. Mas não é só o fim que impressiona, o início, a forma como cada elemento se encaixa em uma escala de espaço e tempo. A fase intermediária, toda a aventura narrada de forma tal que você fica cansado juntamente com os personagens. É um livro inesquecível.
  • 1984. Extraído da wikipédia, eu pego a definição perfeita do que esse livro representa:
    George Orwell escreveu-o animado de um sentido de urgência, para avisar os seus contemporâneos e as gerações futuras do perigo que corriam, e lutou desesperadamente contra a morte - sofria de tuberculose - para poder acabá-lo.
    É isso. O que mais preciso dizer sobre 1984 ?
  • O menino que Enganou o Gigante. Um livro da coleção fantasminha. Baseado na história de Tamara Kitt com o texto em português de Stella Leonardos. Ganhei esse livro na minha festa de aniversário de 88 (fazia 8 anos), da minha "tia" (entenda professora) Karla, da segunda série. Porque esse livro é inesquecível ? Foi o primeio livro que não parecia um brinquedo de criança que eu li sozinho sem ajuda de ninguém. Antes disso, apenas livros de capa e folhas duras e cujas as histórias eram basicamente os desenhos ou livros que faziam parte da escola (textos dos livros escolares da alfabetização). Mas o que quero dizer é: embora não tenha sido a primeira leitura de fato, é o que eu assumo ser o meu primeiro livro "adulto" (ok, infantil pós alfabetização !). O livro que marcou a transição das figuras com texto para o texto com figuras.
Entre os meus livros, tenho obras como Drácula, O Código Da Vinci, Divina Comédia, Eurico - O Presbítero, Os três mosqueteiros, Camões, vários livros de Agatha Christie, Machado de Assis e Érico Veríssimo, entre outros (tenho aproximadamente 70 livros, de diferentes níveis). Essa pequena lista não representa os livros que considero bons, apenas os que me marcaram. "Olhai os Lírios do Campo" está ali, bem anotado, um exemplo que eu nunca colocaria na lista de bons livros (ainda que para muitos seja).

Aproveitando a deixa, como eu disse, eu fui obrigado a ler "Olhai os Lírios do Campo", mas quero deixar claro que, comigo, essa obrigação nunca refletiu como opinião sobre um livro. Eurico - O Presbítero e Memórias Póstumas de Brás Cubas representam livros que li obrigado e gostei muito de ter lido.

E, por favor, lembre-se que eu montei essa lista com base em livros que eu possuo, assim, Isaac Asimov, A Arte da Guerra e tantos outros que eu já li e não possuo, não estão inclusos. A lista não possuí qualquer tipo de ordenação lógica.

Saturday, December 12, 2009

Das nuvens para o desktop

Estava procurando uma forma de integrar melhor meu desktop com o Remember The Milk, pois a extensão para o Gmail e o acesso direto ao aplicativo não estavam dando conta das minhas necessidades.

Descobri que boa parte do que agendo como tarefa realmente chega por e-mail, mas a menor parte que não estava sendo corretamente coletada e armazenada estava produzindo um efeito muito desagradável.

Por esse motivo fui olhar que eu podia fazer.

Primeiro tentei o Tasque, é bom, mas não era o que eu queria. Aí eu fui o olhar o widget para o KDE, bonito, bem integrado, mas confesso que não gostei. Não gostei da forma que esse widget funciona porque ele não suporta adequadamente tudo que eu queria. Além disso, me pareceu muito lento na conexão com o servidor.

Por foi quando estava buscando alternativas que eu encontrei o Prism. Fiquei imaginando quão atrasado estou em não conhecer esse aplicativo, mas ignorei solenemente isso e o testei. Esse programa está disponível no AUR mais próximo de você e no repositório do Ubuntu.

Tudo que ele faz é criar um atalho (arquivo .desktop) com um comando que acessa seu aplicativo on-line. Esse comando você pode copiar e colocar em um local qualquer. Por exemplo, eu coloquei no menu do KDE e em seguida deletei o atalho original.

No caso do RTM, a sugestão geral é utilizar a URL criada para o Google. O resultado é fantástico. Ele abre rápido, pois não é um navegador completo. Acessa diretamente o serviço. Se desejar, pode habilitar o login automático. Sincroniza-se rapidamente com o serviço on-line. Enfim, é perfeito. É o que eu queria.

Aí eu comecei a pensar nos demais aplicativos da Web 2.0 que não deram certo comigo justamente por me obrigar a um passo a mais que era abrir o navegador e em seguida a página do aplicativo. Temos o Google Calendar, que eu uso, mas é subutilizado, o GTalk, porque eu não gosto dos aplicativos de desktop, nem da sua integração com o GMail, o Google Docs, porque as vezes você quer apenas um telefone, e todos aqueles serviços úteis que possuem páginas simplificadas para o sidebar do firefox.

O que ele faz é trazer o aplicativo das nuvens para "a terra" (o desktop). O acesso a internet é fundamental, mas o fato de ser acessado de forma mais simples do que através da página personalizada do Google ou por ser mais rápido do que seu equivalente de desktop, compensa o uso.

Filosoficamente, ele é muito interessante. Ele anda de mãos dadas com o conceito de aplicativos da nuvens, mas sendo um navegador simplificado o aplicativo está preso a uma janela e tem o aspecto e a funcionalidade de um aplicativo convencional.

Não sei se isso vai virar moda um dia, mas tenho três casos de sucesso para relatar: o GTalk, o Google Calendar e o Remember The Milk. Eu também coloquei as URLs do Google Translate e do Google Dictionary e para completar minha lista, estou procurando uma forma simples de checar o clima. Estou entre os recursos do Climatempo (veja o link direto da página de impressão da cidade do Rio de Janeiro, é esse que eu estou testando agora) e a simplicidade do Será que vai chover ?. Vou ficar com o que mais me agradar. Por hora, fico com o Climatempo, mas eu queria algo mais simples, porém, não tão simples quanto o "Será que vai chover ?".

Claro que nem tudo é perfeito. Exemplo disso é o Google Reader. Acessar o Google Reader sem as extensões do Firefox (Better GReader, Read It Later e Adblock) não me agradou muito.

Existe uma extensão para o Firefox, que dispensa a instalação do prism em si (usa o próprio firefox - mas de forma inteligente, não se preocupe !). Registre-se que não gostei da extensão. Quebra um pouco o conceito do prism por depender do firefox e não absorve benefícios, como as extensões.

O Mozilla Prism me permitiu ter uma nova visão dos aplicativos e recursos on-line e eu gostei muito do que vi.

Thursday, December 10, 2009

Porque eu ainda não uso o Google Chrome ?

Uma versão razoavelmente estável do Google Chrome foi lançada recentemente. A pergunta que eu me fiz é: porque usar ou não o Google Chrome ?

Instalei o programa, fiz algumas configurações e a conclusão foi: ainda não, continuarei com o Firefox.

O motivo são as extensões do Firefox. Elas são muito mais poderosas.

Seja para o Delicious e ou Read It Later, os recursos no Firefox são mais interessantes. De fato, eu somente uso o Read It Later devido a excelente integração com o Firefox.

Mas o que eu achei mais foi o Adblock, que existe para o Google Chrome, mas não passa de uma sombra frente a versão do Firefox. Eu não navego sem um Adblock minimamente configurável.

Também senti muita falta do DownThenAll, POW, Better Gmail, Highlighter entre outras. Essa extensões entraram no meu ciclo de trabalho que não seria agradável não usá-las (embora seja possível).

Eu escrevi no título porque eu ainda não uso o Google Chrome ? O motivo do ainda é que eu acredito que seja inevitável um futuro com um netbook. Sim, eu acredito que um dia isso será tão comum quanto um simples celular. E eu acredito no Google OS, ou seja, no Google Chrome.

Além disso, o Google Chrome veio para ficar e tem estilo. Não apenas pelas novas idéias e conceitos já absorvidos por alguns navegadores (o Chrome não é tão novo assim), como na forma de fazer propaganda. Quem ainda não viu o excelente vídeo promocional do Google Chrome, aproveite. É uma obra prima da propaganda do meio. Sem dúvida !

Tuesday, December 08, 2009

Resolução de um problema de longa data

Tome nota: modificar o tamanho da fonte padrão nas preferências do navegador pode impedir o bom funcionamento de alguns sites. No momento eu estou utilizando a fonte Serif com o tamanho 16.

O site da Lojas Americanas é um exemplo de como a modificação dessa configuração altera consideravelmente o funcionamento do site, pois esse torna-se ilegível se o tamanho da fonte for 14 (para essa mesma fonte).

Esse é um problema de longa data que eu resolvi por acaso hoje. Me sinto um idiota, mas um idiota com a obrigação de compartilhar essa informação.

E que fique registrado que a culpa não é do Firefox e, possivelmente, não é minha, visto que eu acredito que os programadores do site deviam ter amarrado melhor o tamanho e a fonte utilizada, como eles fizeram na região que é responsável por atender o cliente e processar a compra do pedido.

Saturday, December 05, 2009

KDE versus GNOME: Qual é a diferença ?

Embora o título sugira mais um flame war inútil. Eu juro que o meu objetivo não é esse. Trata-se apenas de colocar meu raciocínio pessoal escrito em algum lugar.

O que diferencia esses dois gerenciadores de janelas ?
  • A ferramenta de desenvolvimento da interface gráfica.
  • A forma com que se encontra disponibilizado as opções de configurações.
  • O gerenciador de arquivos.
  • Os aplicativos padrões preferênciais.
Quanto a ferramenta de desenvolvimento da interface gráfica

Você é programador ? Sim ? Então tem muito a acrescentar a essa discussão. Não ? Então francamente, o que pode dizer ? Afinal, o programa está pronto, rodando e funcionando. Para o usuário final que não está interessado em programar para o KDE ou para o GNOME, qual é mesmo a diferença ?
O QT, utilizado pelo KDE, até pouco tempo era considerado inferior ao GTK, utilizado pelo GNOME, porque o QT não era multiplataforma. Isso não é mais verdade e os dois são multiplataformas. O GTK é mais popular, mas se você é programador e fez essa escolha, talvez tenha um motivo de origem estrutural melhor do que simplesmente o resultado final, visto que isso pode ser igualmente obtido em ambos.

Nota-se que esses toolkits são bibliotecas que utilizam C++, assim, não há limitações específicas quanto ao uso deles, mas pode ser mais fácil fazer a coisa X em um do que no outro. De qualquer forma, novamente, para o usuário final, que não irá programar utilizando esses toolkits, isso realmente faz alguma diferença ? Eu acho que não.

Quanto a forma com que se encontra disponibilizado as opções de configurações

Talvez seja a grande diferença entre o KDE e o GNOME. A interface do GNOME oferece o menor número de opções, enquanto o KDE oferece o maior número de opções. No meu ponto de vista, isso pode produzir um impacto muito grande na forma que o usuário convive com o ambiente, ou não.

Imagine que em um belo dia de verão o usuário resolva fazer a configuração Y, que é uma coisa usual. Ele não sabe como fazer isso em nenhum dos dois ambientes. Então ele pesquisa. E descobre que no GNOME essa tarefa pode ser marcada em uma das 4 bas de um aplicativo de configuração encontrado no submenu "preferências". No KDE, é quase a mesma coisa (não existe o submenu preferências, mas sim o "Configurações do sistema"). A diferença é que enquanto nas quatro primeiras abas (e possivelmente únicas quatro abas) do aplicativo do GNOME existe uma 3-5 opções visíveis em cada aba. No aplicativo do KDE existem até 20 opções em cada aba e é provável que exista mais de 4 abas.

Isso significa que o KDE é mais personalizável que o GNOME ? Mais ou menos. Considerando a interface gráfica, não há dúvidas. Considerando que os recursos avançados de configuração do GNOME podem ser acessador pelo gconf-editor, ainda é mais ou menos, mas certamente é mais complexo fazer modificações complexas no GNOME do que no KDE, uma vez que no KDE basta ter paciência de ler o que significa cada uma das dezenas de opções que estão no aplicativo enquanto no GNOME você precisa achar a informação detalhada de qual chave deve ser modificada e como fazer antes de proceder.

Agora, sem ficar em cima do muro, o KDE é mais personalizável. E eu posso dar um exemplo de algo que o KDE faz que não se faz no GNOME. Alterar os botões que existem na decoração das janelas. Sabe onde você tem o "x" para fechar ? Também tem o maximizar, o minimizar e menu para mais opções no canto direito. Algumas das opções desse menu podem virar botões na janela quando usando o KDE e os botões podem ficar onde eu bem entendo, inclusive podem estar em uma ordem pouco natural ou usual. Para constar, eu escolhi esse exemplo porque é um recurso muito antigo, nada relacionado com as inúmeras novidades do KDE 4.

Agora vamos ser sinceros. Você vai usar todos os recursos possíveis ? Provavelmente não. Ter o poder de fazer algo não significa que você vai fazer esse algo. Na verdade isso nem sempre é uma vantagem. Eu gosto de ter todas as opções ao meu alcance, mas isso não significa que eu não entenda porque isso não é uma propaganda muito boa para, por exemplo, cativar usuários do windows.

É aqui que eu divido os usuários do GNOME dos usuários do KDE. Eu sou um usuário do KDE, porque eu quero essas opções de configuração, ainda que eu não use nem um décimo delas e que eu possa passar 2 anos e meio usando o GNOME sentido falta de pouca coisa e gostando.

Entretanto, imagine o cenário onde o usuário recebe o computador configurado. Eu mesmo depois de configurar o KDE somente vou procurar novidades quando ocorre um upgrade de versão. Afinal, novidades não nascem do nada. Ou então quando por acaso sou informado sobre certas possibilidades que eu nunca usei, mas que poderiam tornar meu jeito de fazer as coisas mais fáceis.

Nesse cenário, a diferença do KDE para o GNOME é visual. O menu está lá, assim como o controle de som, os ícones de aplicativos preferenciais, o relógio e tudo mais que clássico nos dois gerenciadores e em outros gerenciadores e sistemas operacionais. A manutenção desse ambiente requer pouco esforço. Nesse cenário, os dois ambientes são bem parecidos, podem ser idênticos, se no processo de configuração assim for desejado.

Como eu disse, é nesse ponto que eu divido os usuários do GNOME dos usuários do KDE. Eu penso que os que estão iniciando agora na informática devem ficar com o GNOME, mas podem ficar com o KDE dependendo de quem esteja orientando e da aptidão desses jovens (de espírito) usuários da informática. O excesso de informação do KDE pode não ser agradável a alguns jovens usuários, mas quando eles quiserem mais e o GNOME não oferecer, o KDE pode ajudar nessa formação, inclusive, permitindo que ele venha a fazer por si a escolha entre o GNOME e KDE, decidindo que querem menos. Aqueles que estão migrando do windows (grande maioria dos usuários do GNU/Linux, não é mesmo ?) vão se sentir mais próximos do GNOME. Da mesma forma, alguns usuários podem ficar com aquela sede de como fazer algo mais, aí é hora de experimentar um sabor diferente. KDE, Fluxbox, XFCE, etc, estão aí para completar a formação educacional e permitir um escolha adequada do gerenciador de janelas independente da opinião de terceiros.

Como eu espero ter deixado a entender, acredito que somente o usuário pode dizer qual é o seu gerenciador de desktops. E somente há uma forma de dizer qual é o melhor para ele. Experimentando cada um e decidindo depois. Até lá, a regra mágica acima pode ser útil.

Quanto ao gerenciador de arquivos.

Quase tudo que você faz no computador é gerenciar arquivos, navegar na web, escrever/ler documentos e jogar. Gerenciamento de arquivos é uma das macro tarefas do usuário de computador. Seu gerenciador de arquivos e você devem ser tão íntimos quanto o possível.

Sem meias palavras, o Dolphin é muito mais poderoso que o Nautilus. Novamente, não vamos discutir futilidades, poder não é tudo, mas isso não significa que a frase esteja errada. A integração embutida com o terminal, o uso de abas E divisão de janelas, uso do filtro, melhor controle do previews, visualização, exibição em grupos (excelente para quem tem muitos arquivos no mesmo diretório), etc, diz o seguinte, o Dolphin faz tudo que o Nautilus faz e faz muito mais. Curiosamente, o Konqueror (antecessor do Dolphin) mais mais ainda que o Dolphin, mas talvez seja apenas uma questão de nível de desenvolvimento do gerenciador de arquivos.

Particularmente eu vejo o Dolphin como uma evolução que manteve suas raízes de KDE, mas que aprendeu um pouco com o Nautilus (sim, com ele). As opções padrões do Dolphin são muito parecidas com as opções do padrões do Nautilus.

De qualquer forma, seguindo a premissa do item anterior, as vezes mais é menos e isso não é uma crítica. É uma questão de gosto pessoal.

É importante perceber que é difícil não usar o gerenciador de arquivos padrão do seu ambiente de desktops, assim, quando você escolhe o KDE ou o GNOME, você também escolhe o Dolphin ou o Nautilus. E como é um aplicativo que você terá de usar durante muitas atividades é um ponto importante de observação.

Quanto aos aplicativos padrões como um todo.

Qual é o melhor navegador de internet ? Konqueror, do KDE, ou o Epiphany, do GNOME. Hum !!! Você respondeu: Mozilla Firefox ? Se sim, você está com a maioria.

E qual é o melhor editor de imagens ? Krita ou GIMP ou outro ? Eu uso GIMP e o KolourPaint (para dizer a verdade eu uso o KolourPaint e duas funções do GIMP).

E qual é o melhor leitor de PDFs ? Okular, Evince ou o Adobe ? Para pdf, eu uso o Okular quando estou no KDE e o Evince quando estou no GNOME, mas de vez em quando, infelizmente, eu uso o programa da Adobe. Por necessidade, não por opção, que fique isso registrado.

E o editor de textos simples ? Kate ou Gedit ? Eu uso o vim (e o Gvim).

Quantas dúvidas ...

Tanto o KDE quanto o GNOME possuem seus programas favoritos. Sabe o que eu faço. Uso o melhor aplicativo em cada caso. Não me deixo influenciar pelo desejo do KDE ou GNOME. Simples assim. Os dois ambientes permitem configurar aplicativos padrões para cada função e para cada tipo de arquivo, então, não há problemas (pode haver trabalho, não problema).

Muito da discussão que gira envolvendo o KDE e o GNOME é sobre esse ponto.

Isso deve-se, principalmente, ao fato de que o criadores LiveCDs tendem a respeitar a opinião do gerenciador de janelas que está no LiveCD. Uma vez instalado, a menos que use um HD de 10 GB, não há motivos significativos (bom, até existem, mas aguarde um pouco) para não ter tanto o KDE quanto o GNOME instalado. Você não precisa instalar todos os aplicativos do GNOME e todos do KDE, mas não usar o Evince porque não quer instalar pacotes do GNOME é não é produtivo (supondo que você ache o evince mais produtivo que o Okular, é só um exemplo). Minha instalação tem tudo que tem direito e mais ainda e eu não consumo 10 GB de HD. Se eu tivesse somente 10 GB, seria difícil, porque eu preciso de espaço para meus arquivos pessoais, mas meu HD é de 750 GB. Tudo bem ... se fosse de 40 GB já não apresentaria nenhum motivo para a economia de espaço em HD.

Um aspecto técnico relevante é que existe uma certa lerdeza em executar um aplicativo QT no GNOME ou GTK no KDE quando o processador é lento. Digo isso porque eu levava quase três vezes mais para abrir o Kate de dentro do GNOME do que o Gedit em um Pentium III. Para isso eu diria o seguinte: quando o tempo de uso do programa é aproximadamente igual ao tempo de abrir o programa, o programa tem que abrir rápido. Isso se aplica ao editor de textos básico e ao emulador de terminal. Do contrário, quando o tempo para abrir o programa é muito menor que o tempo de uso do mesmo, não há um problema aqui. Se o processador é "novo" (maior que Pentium IV ou equivalente) não há problemas perceptíveis nesse ponto se houver quantidade suficiente de memória RAM. E esse é um aspecto a ser pensado.

Hoje é difícil ter uma máquina nova com menos de 1 GB de RAM. Uma máquina que tenha 512 MB pode ter dificuldade de carregar programas do QT no GNOME ou GTK no KDE (tudo depende do programa, claro, programas pequenos são pequenos porque não consumem muito recursos). Algumas pessoas assumiam a "regra da maioria" se a maioria dos seus aplicativos for GTK, use o GNOME, se a maioria dos seus aplicativos for QT, use KDE. Se possuí 1 GB ou mais, não se limite por isso.

Por fim, existem aplicativos que rodam apenas em um sistema e não no outro. Lembro-me que o superkaramba não rodava bem no GNOME (na prática, não rodava, porque ele não se comportava bem rodando). Hoje, você não pode colocar os mini-aplicativos do plasma no GNOME. No GNOME há equivalentes, mas não são os mesmos. Eu não diria que isso é fundamental, mas já houve um dia que eu julgava que era muito importante ter o superkaramba no meu computador. Hoje, eu vejo que em parte eu precisa de um "monitor de sistema" e "um lugar para colocar os meus ícones prediletos", ou seja, eu abri os horizontes. Antes eu procurava executar um programa específico para resolver um problema, hoje eu resolvo o problema com o melhor programa que eu encontro.

Conclusão
Normalmente quando eu lia textos com o título de "KDE vs GNOME" havia uma grande influência de quem escreve em focar dois pontos. O seu próprio gosto pessoal sem pesar o que seria melhor para terceiros e os aplicativos padrões que acompanham o pacote escolhido. Eu eliminei esse último ponto.

Acredito que essa discussão somente tem procedência quando há limite de hardware. Espaço em disco, processador muito antigo e/ou memória RAM limitada. Fora isso, o melhor é usar o melhor dos aplicativos.

E eu tentei não deixar minha opinião sobre o KDE influenciar na forma com que eu coloquei as diferenças. O que é melhor e o que é pior em termos absolutos é irrelevante. Minha opinião está escrita, mas não é absoluta. O que eu posso fazer ? Sou eu que escrevi, é impossível fugir de mim mesmo para escrever um texto.

Durante o tempo que passei no GNOME, eu muitas vezes pensava: se eu pudesse fazer um split da janela ou então pena que eu não posso colocar o botão "manter a janela acima das outras" na janela e por aí vai.
Na época o meu computador não era muito bom e a memória RAM disponível era limitada, eu tentava me virar da melhor forma possível com os aplicativos do próprio ambiente que eu estava. Esse foi um dos fatores que me fizeram comprar um pente de 1 GB adicional (fiquei com 1,5 GB) para não ter que viver dos aplicativos de apenas um único ambiente. De fato, olhando para os meus hábitos, eu vejo 4 aplicativos GTK, 5 aplicativos QT, 4 aplicativos java e 3 de código fechado, como os que eu mais uso.

Algumas pessoas implicam com o visual do programa GTK no KDE e vice-versa. Caros, isso é configuração. Você pode fazer o que quiser e sem desculpas nos dois ambientes. Portanto, dizer que usar um programa GTK no KDE é algo feio, não é verdade, e vice-versa.

Por fim, uma coisa que eu aprendi nos últimos anos é que nossos hábitos são muito dinâmicos, mesmo quando fazemos as mesmas coisas todos os dias, pois o mundo, o ambiente, muda e fazer as mesmas coisas todos os dias significa aprender um pouco de algo diferente todos os dias.

Sunday, November 29, 2009

De volta ao KDE

Quase dois anos e meio depois de ter iniciado minha temporada no GNOME, estou de volta ao KDE.

O motivo de minha volta é circunstancial. Mas eu deixei o KDE na versão 3, volto na versão 4 e muita coisa mudou durante minha temporada no GNOME.

Antes de mais nada: continuo gostando do GNOME. Das coisas que aprendi com o GNOME, posso listar o seguinte:
  1. Interface limpa é melhor. O visual clean permite um melhor desempenho do que o visual com muitos botões chamativos. Em outras palavras, o clearlooks é o melhor tema que conheci até hoje quando o assunto é produtividade. Antigamente eu utilizava um tema que hoje sequer está disponível por padrão, mas, por exemplo, fazia os botões ficarem com aspecto 3D, roliços, isso me parecia bonito antigamente, mas não mais.

    Para fazer o visual do KDE ficar parecido com o do GNOME, selecione o tema GTK+ e certifique de ter um .gtkrc e .gtkrc-2.0 no diretório $HOME. No ArchLinux, instale o gtk-kde4 e gtk-qt-engine para gerenciar o tema GTK+ do KDE. Um desses (acho que o gtk-qt-engine) vai criar uma gtkrc no diretório de configurações o KDE (que está em ~/.kde/share/configs) copie-o para o diretório $HOME com os nomes de .gtkrc e .gtkrc-2.0, após concluir a configuração para tornar a aplicação do tema mais genérica possível.

  2. Sempre gostei da cor "areia" ou "parda" ou "terra de siena", como preferir. Nunca fui fã da cor azul. Antigamente eu utilizava o tema de cores "Desert" que ainda existe no KDE 4. Mas com o tempo no Ubuntu eu me encantei com as cores dele e passei a utilizar as mesmas cores em cada GNU/Linux que utilizei.

    E continuo utilizando agora no KDE, mas não imagina o trabalho que deu para criar um tema de cores similar ao do Ubuntu antigo (sim, porque o atual está com alguns tons mais escuros).

  3. O tema de ícones não contradiz as duas regras acima. Estou utilizando o HumanityPNG tema de ícones que se assemelha ao tema de ícones Human, também do Ubuntu para o GNOME.

    É facílimo instalar esse tema de ícones no ArchLinux.

  4. Sem tela de apresentação, o Desktop abre mais rápido.

  5. O GNOME me ensinou como usar sempre duas barras de tarefas e o menu está na barra de tarefas superior.

    Não suporto discussões sem fundamento. Quero dizer, tem gente que não admiti utilizar uma barra de tarefas no GNOME ou duas no KDE. Para mim isso é besteira. Antigamente eu utilizava uma barra de tarefas. Possivelmente porque passei boa parte do meu aprendizado inicial utilizando o Windows e o KDE ao mesmo tempo. Em 2004 eu não usava mais o Windows, até o meu GNOME, configurado a meia boca tinha apenas uma barra de tarefas, quando mais o KDE, que de estimulava a usar apenas uma barra de tarefas e era meu gerenciador padrão. Quando iniciei minha temporada no GNOME eu tive que abraçar algumas coisas que o GNOME tinha como filosofia, entre elas estava as duas barras de tarefas. Aprendi a gostar disso.

  6. Esteja aberto a novidades. Para usar o GNOME eu tive que abrir minha mente e aprender a fazer as mesmas coisas de forma diferente.

    Não imagina como isso foi importante para mim, não apenas como usuário de computador (aprendi as vantagens do GTK), mas como pessoa. Eu revi muitos hábitos que dava como perfeitos e hoje tudo está melhor. E estou sempre tentando ver as coisas de uma forma diferente para permitir o melhor aproveitamento de tudo.

  7. Aprendi que usar a aba "Locais" é mais rápido e eficiente que utilizar a árvore de diretórios.

  8. Quase dois anos e meio depois e eu ainda sentia falta da capacidade de dividir a mesma janela em duas janelas mantendo a árvore de diretório ou Locais. Incrível ! Aprendi a não depender disso, especialmente por que tive dicas no comentários e porque o Nautilus incorporou abas o que diminui muito minha dificuldade.
Impressões sobre o KDE 4.3
  1. Ele está estável. Eu não o estaria utilizando se ele não estivesse estável.

  2. O Dolphin ainda pode melhorar mais. Ele me parece um port modificado do Nautilus (ok, eu sei que ele é escrito em QT e o Nautilus é GTK, estou falando de ideologia, certo ?) que une o que há de melhor do Nautilus com o Konqueror.

  3. Gostei muito do Plasma. Seus recursos são extraordinários. O recurso visual excelente sem perda significativa de memória o desempenho. Muito melhor que utilizar o compiz (supondo que não queira priorizar o visual, claro).

  4. O estilo KDE de deixar todos os botões de configuração acessíveis desagrada quem é usuário nativo do GNOME na maior parte das vezes. Eu me descobri indiferente a isso.

  5. O KDE tem suporte nativo a troca automática de papel de parede. Isso significa que eu não sou mais dependente do problemático Wallpaper-tray.

  6. Quando eu abri as configurações do KDE, eu pensei que tivesse executado algum aplicativo com o nome: import_config_from_gnome. Por que muitas das configurações que eu iria modificar já haviam sido modificadas. O menu, por exemplo, manteve-se quase igual. Importou aplicativos inseridos pelo Alacarte. A Associação de arquivos e os aplicativos padrões também foram importados, mas de forma inteligente (quero dizer que quando eu abria um diretório eu não abria o nautilus, mas ao abrir um pdf eu abria o evince). Como eu usava os melhores aplicativos para cada função, essa característica foi adorável.

  7. Quando você executa qualquer ação, tipo copiar um arquivo, ela ocorre de forma bem discreta e é gerenciada via um recurso na área de notificação. O GNOME também tem uma coisa parecida, mas essa é muito mais acoplada ao sistema e silenciosa.

  8. Uma vantagem de mudar agora, é que no momento é o GNOME que vai sofrer uma atualização significativa. Pela filosofia de trabalho do GNOME, eu não acredito que venha a se reproduzir o mesmo "desastre" que foi a atualização do KDE para a versão 4.0. Mas alguns problemas serão inevitáveis. Por outro lado, o KDE 4 deve ficar cada vez mais estável.

Sunday, November 22, 2009

Abrir resultados da pesquisa no Google em uma nova janela

Gosto de abrir o resultado de um pesquisa no Google em outra janela. Antigamente eu utilizava uma extensão, mas como muitos projetos, ela evoluiu e ficou pior, acrescentando inúmeros recursos que eu não quero e que não consigo desabilitar.
Assim, eu criei meu próprio script greasemonkey, que segue abaixo.

// ==UserScript==
// @name Google Results in New Window
// @namespace googleresultsnewwindow
// @include http://www.google.*/search*
// ==/UserScript==

var links = document.getElementsByTagName('a');

for(var i = 0; i < links.length; i++)
{
var link = links[i];
var url = link.href.toString();
if(link.hasAttribute("onmousedown")){
link.target="_blank";
}
}
Para constar, ninguém precisa desse script para apenas obter esse resultado final. Pois é possível forçar esse comportamento acessando as preferências da pesquisa e selecionando a opção que diz "abrir uma nova janela para os resultados de pesquisa" ou algo parecido. Está curioso para saber porque criei algo que sabia que seria desnecessário para obter o mesmo resultado ? É mais fácil habilitar e desabilitar o recurso utilizando o Greasemonkey do que utilizando as preferências do Google.

Monday, November 02, 2009

Compartilhando informação com o Google Reader

Já faz muito tempo que deixei de compartilhar itens que leio no Google Reader nesse blog. Não sei se vou retornar esse hábito, mas seja como for, por causa de um comentário de um amigo, eu fui dar uma olhada a quantas andava a evolução do "share" do Google Reader e me impressionei.

Há muitas modificações que foram feitas ao longo do tempo que eu não dava mais a mínima por não usar o recurso, mas somente a pouco eu vi todas as modificações juntas e o resultado é que podemos compartilhar textos com notas, comentar sobre documentos compartilhados por terceiros ou mesmo sem compartilhar, localizar pessoas utilizando ferramentas de busca por nome e/ou interesse, usar o recurso "Like" para marcar textos que tenha gostado e usar esse recursos para ver quem gostou daquele item (talvez seja alguém que valha apenas seguir). Você pode tornar o seu perfil público, mas impedir que alguém te siga (eu acho que fiz isso uma vez sem saber do que se tratava, desculpas aí, ok ?) ou torna ele privado e determinar com quem você quer compartilhar.

Mas recentemente, a região de "Explore" que permite você explorar (e se perder explorando) novos itens, acrescentou o "Popular items" (não sei como foi feita a tradução, "Itens populares" ou "Tópicos populares" ?) que permite visualizar tópicos que possuem um número muito alto de "pessoas que gostaram do tópico" (recursos "Like").

Enfim, compartilhar e receber informação com o Google Reader ganhou recursos realmente interessantes. A ponto de que voltei a usar essa parte do sistema.

Quem quiser seguir os meu itens compartilhados pode acessar a informação dessa página. É, entretanto, necessário notar que não há um botão "Follow" nessa página. Se assinar essa página ela entra no Google reader como um feed RSS qualquer e não no sistema interno do Google Reader. Eu tentei me localizar pela busca existente no "sharing settings" mas não me achei (será quer é para que eu não me ache mesmo ?). Então, caso isso não dê certo, use o e-mail que publico no blog para colocá-lo nos seus contatos. Isso deve permitir que você me encontre. Se isso também não der certo (?) e você ainda não desistiu de me seguir, você pode assinar um dos feeds que eu compartilhei na página pública, buscar por algo que eu tenha marcado com o "Like" (quase tudo que compartilho eu marco com o "Like") o que permitirá ter acesso ao meus itens compartilhados em uma página que terá o botão "Follow" para você clicar. Essa última idéia dá trabalho, mas funciona sempre.

Por que seguir alguém ?
  • Alguém se deu ao trabalho de filtrar a informação para você separando o que realmente é bom do que não é bom, supondo que escolheu seguir uma pessoa com o perfil que te agrade, claro. Você economiza tempo e trabalho. E também não precisa seguir todos os RSS do mundo.
  • Precisa de mais de um motivo ? Bom, você pode manter uma conversação inteligente longe do blog original que pode não estar com comentário tão inteligentes assim.
E o lado ruim ?
  • Você segue 10 indivíduos com mesmo perfil ? Você terá 10 vezes o mesmo tópico compartilhado.
  • Encontrar pessoas que te agradem seguir nem sempre é tarefa tão fácil quanto parece.
  • Têm gente que simplesmente marca todos os tópicos de um certo RSS para compartilhar. Fuja disso, a menos que seja algo necessário para ter diálogos em torno daquela fonte que não permite comentários - ou não aceita seus comentários e de seus pares (?) -, mas se não for o caso, assine o feed original.

Thursday, October 15, 2009

Rapidinhas, não tão rápidas

Desde de julho eu não escrevo. Basicamente eu estou com a corda no pescoço e com o carrasco puxando ...

Somente consegui um tempo para escrever no blog apenas porque torci o pé e o analgésico/anti-inflamatório é forte.

O último tópico "Descobrindo o seu ip real" está desatualizado.
Por conta disso, eu sugiro o uso de
alias myip="links -dump http://jfmitre.googlepages.com/ipsimple|head -1|cut -d',' -f 1"
no lugar do comando previamente comentado. O comando ficou um pouco mais complicado, mas é mais provável que esse serviço não sai do ar. Eu não vou atualizar o outro tópico...

Não pude deixar de notar esse tópico de hoje. Fiquei impressionado com o unp. Ele resolve 70 % das dúvidas que eu tenho que responder sobre descompactar no terminal e ainda elimina uns 10 atalhos que possuo para descompactação em lote de arquivos.

Vejamos a configuração de notebook Acer Aspire 5738-6922
Processador & Chipset
Intel Core 2 Duo T6400 - 2.0GHz, Cache L2: 2MB, FSB: 800MHz.
Memória
3GB DDR3 1066MHz.
Expansível até 4GB.
Armazenamento
HD de 320GB - SATA II, Buffer de 8MB, 5400rpm.
Drive DVDRW - lê mídias double layer.
Tela
Tela de 15.6" com tecnologia Acer Cinecrystal.
Resolução nativa: 1366 x 768 pixels.
Gráficos
Intel GMA 4500MHD ( 128MB dedicado ).
Multimídia
WebCam de 1.3 megapixels.
Interface I/O ( entradas e saídas )
4 USB.
1 RJ-11 ( modem ).
1 RJ-45 ( rede Ethernet ).
1 saída de áudio para fones de ouvidos ou lato-falantes externos.
1 entrada para microfone externo.
1 saída VGA para monitores externos.
1 HDMI.
1 leitor de cartões de memória 5 em 1: SD, MMC, MS, MS PRO e xD.
Comunicação
modem 56Kbps.
rede Gigabit 10/100/1000Mbps.
rede Wireless: Wi-Fi 802.11a/b/g/n.
Interface do usuário
Gabinete azul onix, teclado preto.
Teclado com Ç.
Dimensões e peso
peso: 2.8kg.
Sucesso quase absoluto em instalar o Ubuntu. Problema apenas com o microfone interno, ao qual eu nem sei se existe mesmo, e com o headfone, que eu não tentei configurar. O resto, perfeito. Mais ou menos 1100 frames por segundo de vídeo (suficiente para programas 3D que não sejam jogos atuais). Ótima qualidade de som, saída HDMI e memória DDR3.

Esse notebook foi comprado para o laboratório e ficou sob minha guarda por eu ser o primeiro que irá utilizá-lo. Me ordenaram instalar o Windows XP e o Linux que desejasse. E quem foi que disse que o notebook reconheceu o Windows XP ? Eu sei que tem suporte porque há uns 40 drivers (sem brincadeiras) para instalar posteriormente ao OS. Mas eu não consegui passar das primeiras telas do instalador (E é o Windows XP original, ok ? E eu usei duas mídias distintas de CD !). Não imagina minha alegria tristeza com a ausência do Windows , especialmente quando eu abri uma garrafa de vinho para comemorar

Mas o que me deixou chateado nesse notebook foi o Linux original do sistema (sim, o notebook veio com um GNU/Linux). Além do patético particionamento do sistema, ao qual 10 GB era tudo de Linux e o restante FAT32, o sistema iniciava no terminal (e se tinha um X funcional, não funcionou comigo) e não tinha toda configuração instalada. Quando eu vi o particionamento eu nem me dei ao trabalho de ver outras coisas. Ah ! O
shutdown -r now
também não funcionou e eu não faço idéia do motivo. Mas como ele travou ao desmontar o HD, eu suponho que algum serviço teimoso não foi corretamente desativado ou que os scripts estavam corrompidos. Seja como for, se fosse meu primeiro contato eu poderia nunca mais querer ouvir falar de Linux na vida e com justa causa.

O livro não está abandonado, apenas não esperem uma nova versão esse ano (especialmente porque desejo manter em PDF apenas versões estáveis e redondinhas do código que qualquer um pode acessar a qualquer hora - e que também anda parado a um bom tempo). As coisas estão realmente muito apertadas para mim e eu não vi muitas modificações no ubuntu 9.10 que justifiquem um esforço concentrado nesse momento.

[esqueci]
Experimente o htop. E se desejar, para não ter que reaprender a digitar htop no lugar de top, sugiro adicionar as linhas abaixo ao ~/.bashrc
# Use o htop no lugar do top, se existir htop
alias top='[ -f /usr/bin/htop ] && htop || /usr/bin/top'
[/esqueci]

Se tiver algum erro grave de português nesse texto, favor, ignore. Analgésicos não ajudam em nada na concentração.

Tuesday, July 21, 2009

Descobrindo o seu ip real

Dica especial para quem não se conecta diretamente na internet e usa um roteador para intermediar a conexão (característica típica de quem está conectado a partir de uma rede interna).

Para descobrir o seu ip real, normalmente uma busca na internet retorna sites como ShowMyIP. Para quem não sabe, existem milhares de sites com essa capacidade, pois isso não é nenhum recurso extraordinário.

Mas mais fácil ainda é adicionar as linha

alias myip='lynx -dump http://www.showmyip.com/simple/'

no ~/.bashrc.

Assim, quando quiser saber o seu ip real, basta digitar myip no terminal.
Nesse caso, é necessário ter o lynx instalado no computador. Para quem prefere o links, pode-se usar a linha

alias myip='links -dump http://www.showmyip.com/simple/'

no lugar da linha original.

Sunday, July 19, 2009

Dicas de Juliet Kemp

O Linux Today resumiu uma coleção de dicas de Juliet Kemp do Server Watch.

Quem não viu, vale apena ver. Algumas coisas, como as dicas para configurar o PS2, PS3 e PS4 são como descobrir algo que está diante dos seus olhos todos os dias e nem ao menos se importou em olhar para saber do que se trata. Afinal, "todo mundo configura" o PS1, mas quantos sabem o que é o PS2 ou o PS4 ? É claro que algumas dicas são mais do mesmo para alguns, mas para outros ...

Não se contente com a seleção do Linux Today e verifique as publicações não selecionadas. Aposto que vai descobrir alguma coisa interessante.

Tuesday, July 07, 2009

Gmail não é mais um aplicativo beta e hoje não é primeiro de abril.

Essa mensagem é um daqueles ecos da internet que vale apena repetir. O Gmail não é mais um aplicativo beta.

Já acreditei que esse dia nunca chegaria. Já até critiquei o Google por redefinir o conceito de aplicativo beta sem ter o direito disso. Mas o dia chegou... merece um: Uau !!!

E para não dizer que não falei dos demais, parece que o Google Docs e o Google Calendar também deixaram de ser beta...

Vale lembrar aos saudosistas (?) de plantão que o Gmail permite que você volte a usar o logo com o nome beta escrito...

Monday, July 06, 2009

ArchLinux: Um mês depois...

A exatamente 1 mês atrás eu migrei para o ArchLinux. Eu normalmente escrevo o relato "uma semana depois", mas eu queria adquirir mais experiência com o sistema para ter o que falar dele.

Primeiro ponto: o AUR. Se quando eu instalei o sistema eu somente senti falta de 1 (um) aplicativo, hoje eu tenho 20 aplicativos do AUR instalados. Me parece que a química, física e matemática não conta com um número muito grande de votos... pacote excelentes, como o gElemental*, estão com pouquíssimos votos.

Até me inscrevi e fiz uns comentários pelo AUR até perceber que não me lembro onde fiz os comentários, ou seja, ainda preciso me adaptar melhor com o sistema da comunidade.

Por falar nisso, eu "acidentalmente" conheci um aplicativo chamado yaourt que ajuda muito a baixar um aplicativo do AUR. Entre outras coisas, ele permite atualizar pacotes do AUR. Ainda não experimentei esse ponto (instalei o aplicativo a 2 dias) e não posso opinar quanto a eficácia da solução, mas dada a popularidade dela, deve funcionar muito bem.

A estabilidade é excepcional. Tenho até medo de falar de futuro, mas posso falar de passado. Não houve erros. Não houve problemas. E o sistema de gerenciamento de pacotes é muito robusto.

Para dizer que eu não vi nada de diferente, o camarada de gerencia o virtualbox-ose (que não é o virtualbox_bin) alterou a versão do módulo do kernel dois dias antes do kernel ser atualizado no repositório do core. Isso me confundiu um pouco, por que o pacman não funcionava com a filosofia que eu conheço. Isso fez que eu pensasse que ele tinha feito uma coisa, mas ele fez outra...

Inclusive, isso lembra que o kernel foi atualizado nesse meio tempo. E quando digo isso, eu lembro do drive NVIDIA. Pois... não foi observado qualquer problema nesse ponto. O kernel e o módulo foram atualizados no mesmo momento (e eu não vi como).

Ainda sobre a atualizações de pacotes, duas coisas comuns me chamaram a atenção. NÃO DEVE-SE ignorar mensagens durante a atualização dos pacotes. LER essas mensagens e AGIR (ainda que depois) evita problemas desnecessários. Felizmente, o administradores devem conhecer um pouco a cabeça de usuário (bom, eles são usuários !!!), porque a mensagem que eu devia ter lido estava no portal... (e isso parece ser um fato comum).

Lembra que eu mencionei o OpenFOAM (que era o motivo de eu ter migrado para o openSUSE), pois é... está compilado e rodando no ArchLinux. Ok ... eu precisei trapacear. Eu compilei a primeiro em outro sistema e depois recompilei com o gcc do ArchLinux, sem fazer um "wcleanAll". Existe algum problema de biblioteca/include que não permite que eu compile o sistema inteiro do zero dentro do ArchLinux (acredito que a versão do binutils seja nova demais e eu optei por não resolver isso da forma correta - seguindo filosofia do OpenFOAM), acredite em mim quando digo que isso não é um problema. De forma que o mais importante é que até o OpenFOAM está funcionando.

Bom, o resumo geral dessa história é que eu tive o mês mais produtivo do ano. Eu realmente espero que essa "lua de mel" dure muito.

* O gElemental não vai instalar fácil no sistema. É necessário editar um arquivo do source, que está dentro do tar.bz2 com uma dica que está nos comentários. Depois modificar o md5sum dentro do PKGBUILD para então conseguir instalar. Mas é a melhor a mais bonita tabela periódica que eu conheço para o GNU/Linux

Friday, July 03, 2009

Os bons hábitos do usuário do computador

Há recomendações que deviam ser seguidas por todos nós, usuários.

Infelizmente, como toda recomendação ou regra, elas são questionadas por alguns e não são seguidas por muitos.

Da série de tópicos: faça o que eu escrevo, mas não faça o que eu faço, proponho relembrar alguns desses bons hábitos, que como já induzi a crer, não são completamente seguidos por mim, mas não deixam de ser bons hábitos.

A maior parte dessas dicas são aplicáveis em qualquer sistema operacional.
  1. Use boas senhas. Nada de 123456, ou password, ou data de aniversário, etc.
  2. Modifique as senhas padrões dos seus aplicativos. Se usa aplicativos ou hardwares com senhas padrões, modifique-os. Você pode não ser dono de uma grande rede, mas não quer dor de cabeça do mesmo jeito.
  3. Não use espaços e/ou caracteres especiais nos nomes dos arquivos. Prefira letras minúsculas separadas por underlines ou notação estilo "WikiPage" (desse jeito que escrevi). Nada de apóstrofo, aspas, ponto de exclamação ou interrogação, nem símbolos como dóllar, hash, arroba, etc. O dóllar ($), por sinal, é um terror, pois $nome é variável, assim, um arquivo que se chame "algo$nome" somente é "protegido" com aspas simples ou usando barra invertida. Esse tipo de caractere trás muitos problemas.
  4. Registre os nomes dos aplicativos que possui e usa. Qualquer gerenciador de programas descente possui esse tipo de habilidade. Não confie na memória. Muito embora, seja interessante fazer uma limpeza no arquivo eliminando aqueles aplicativos que não te foram úteis durante as atividades.
  5. Faça backup. Preferencialmente do sistema inteiro, mas impreterivelmente dos arquivos pessoais em mais de uma mídia/tecnologia (se possível). Um gravador de DVD custa muito pouco hoje em dia, a mídia também é barata.
  6. Faça backup dos seus aplicativos online. E não adianta cobrir o sol com a peneira. Se suas notas estão no evernote e os seus e-mails no gmail, faça backup disso também. Não ignore essa necessidade.
  7. Anote e guarde suas configurações mais usuais. Parece que é a mesma coisa que um backup, e até é, se for para restaurar as configurações no mesmo ambiente. Mas aqui eu estou falando de manter um registro de todas aquelas configurações que de tão intuitivas você nem lembra que são uma alteração que você mesmo induziu ao sistema. Se um dia precisar de usar esses recursos em outro sistema, não tem jeito do backup ser tão eficiente assim.
  8. Não tenha receio de danificar o sistema. Não é a mesma coisa de "pode meter o martelo". O que quero dizer é que há pessoas que não fazem testes porque temem pelas conseqüências da estabilidade (eu mesmo faço isso, e em muitas ocasiões, com boas justificativas técnicas e morais). Mas esse temor pode lhe custar um grande benefício. Vide minha transição para o Arch Linux, eu ganhei muito, perdi nada e não tinha feito isso antes por receio de ficar improdutivo por muito tempo.
  9. O melhor programa é aquele que você sabe usar e que faz o que você quer fazer. Por até haver um programa que seja tecnicamente melhor que outro, mas as vezes, mudar é como utilizar uma bomba para quebrar um vaso de vidro. Use a melhor ferramenta para o seu objetivo e ponto final.
  10. O programa que você não usa, evolui. Mude quando o novo programa for a escolha certa. Completando o item anterior, a melhor ferramente pode ser outra no futuro. Não deixe de mudar. O equilíbrio entre o item anterior e esse é o que estimula a produtividade. A falta de equilíbrio gera problemas de diversos níveis. E lembre-se do item 8.
  11. O computador é uma ferramenta para um objetivo. Não se esqueça disso.
  12. Crie uma metodologia para gerenciar os seus arquivos. E não se acomode. Deixar muitos arquivos bagunçados no computador é algo fatal. Preferencialmente, essa metodologia deve ser tão simples quanto possível, mas não mais simples do que o necessário, intuitiva, fácil de executar e adapatável a evolução usual das idéias, ou seja, que seja facilmente gerenciável.
  13. Leia os manuais. Certo que há manuais mais extensos do que o tempo disponível para lê-los. Certo também que há manuais menos úteis do que devia. Mas eles existem. Se não quer ler o manual de um programa que não sabe usar, considere usar outro programa. Nota: Tutorias e exemplos ajudam muito, mas não são os bons manuais fontes de tutoriais e exemplos ?
  14. As atividade administrativas são executadas pelo administrador, as de usuário comum, pelo usuário comum. Isso é regra básica para gerenciamento de sistemas.
  15. Mantenha o registro do seu hardware. Colete todas as informações possíveis sobre o seu hardware e guarde em algum lugar seguro. Pode até ser em mídia eletrônica, mas lembre-se de não usar apenas no próprio computador.

Sunday, June 14, 2009

Apresentando um Makefile em detalhes

Não tem muito tem e fiz uma introdução ao comando make. Como mencionado, a forma mais simples quanto possível de apresentar essa questão é utilizando um exemplo que seja tão simples quanto possível e que não seja simples demais para não ficar algo muito superficial. Por isso, escolhi o meu próprio Makefile, criado para gerar um dvi/pdf de um código LaTeX. Portanto, eu vou colocar esse código aqui conforme eu for citando, mas se quiser, baixe o mesmo para acompanhar localmente e fazer suas próprias anotações nele. Eu não vou modificar o Makefile hoje, mas eu posso vir a atualizar/modificar ele no futuro (até irei comentar sobre pontos falhos do mesmo durante a exposição).

Primeiro passo

O primeiro passo é definir o objetivo.

No nosso exemplo: Compilar um código LaTeX, considerando a possibilidade de existir uma bibliografia, um índice remissivo, nomenclatura e glossário. Isso é o mais completo que eu conheço. Além disso, o Makefile deve sempre gerar um PDF e gerar um DVI quando possível. Para gerar o PDF, eu quero que o usuário possa escolher entre gerar primeiro um DVI e depois converter para o PDF ou gerar direto o PDF. Eu também quero que o Makefile facilite o meu trabalho para visualizar o documento e que seja possível eliminar o resultado e o lixo intermediário gerado facilmente.

Esse era o meu objetivo nesse caso. E entenda que eu sei como fazer essas coisas no terminal (o make não faz mágica)...

Em outros casos, pode ser: gerar o programa helloworld a partir do código fonte main.c, incluindo uma forma de eliminar o resultado final e os arquivos intermediários.

Lembrando regras básicas de programação.

Recomendações que não são utilizadas por quem recomenda não são, necessariamente, recomendações ruins....

Comente sempre que achar necessidade e quando não achar também, seja sucinto, mas não omita informações. Entretanto, não se culpe se depois alguém disser que não entendeu o que você queria ter dito. Como senhores do programa, naquele momento parece muito claro o que estamos escrevendo. Depois de um certo tempo, isso tornar menos claro. Então, se possível, reveja suas anotações depois de um certo tempo.

O alinhamento do código é muito importante, mas não precisa ser de 8 espaços, pode ser 1 ou 2. Eu gosto de 2, mas nesse caso do meu Makefile eu utilizei apenas 1 espaço. Dizem por aí que o recomendado é 3.

Sempre que possível, faça a tarefa automaticamente. Não peça ao usuário informações que não sejam necessárias, automatize sempre que possível, sem perder a generalidade.

Por fim, porém não menos importante... escreva como usar o seu código. Isso é para você mesmo se lembrar depois...

O Makefile.

O Makefile começa com um cabeçalho.
Informe o que achar necessário.

# File: Makefile
# Author: J. F. Mitre <http://jfmitre.com>
# Created: Sex 29 Mai 2009 10:14:33 BRT
# Last Update: Qui 04 Jun 2009 21:30:21 BRT
# Notes: Arquivo Makefile para compilar códigos em LaTeX
# Execute "make help" para ajuda
###############################################################################


É educado guardar um CHANGELOG. Eu escrevi o programa em uma tacada só na quinta do dia 04. Na sexta anterior tinha sido o dia que eu decidi fazer o arquivo e escrever as idéias. Então meu CHANGELOG é pequeno. Ainda assim, eu não o divulguei...

Teria sido legal colocar uma nota sobre licença. Eu esqueci desse detalhe...

Definições de variáveis

A primeira parte do Makefile é composta por definições de variáveis.

# Programas Selecionados {{{
########################## PROGRAMAS SELECIONADOS #############################

# Comando que gera compila o código LaTeX. Escolha entre: latex ou pdflatex
TEX = latex
# Comando que visualiza o arquivo .dvi
DVIVIEW = kdvi
# Comando que visualiza o arquivo .pdf
PDFVIEW = evince
# Comando que converte o arquivo .dvi em .ps
DVIPS = dvips

# }}}


Esse bloco acima define quais são os valores das variáveis TEX, DVIVIEW, PDFVIEW e DVIPS. São aplicativos do sistema que fazem aquilo o comentário indica. Esse são os comandos que serão utilizados pelo make ao executar um certa tarefa. Esses comandos foram colocados no primeiro bloco, porque podem ser modificados pelo usuário.

Veja como exemplo a variável TEX. Eu posso usar latex ou pdflatex. O primeiro comando gera um arquivo .dvi enquanto o segundo gera diretamente um arquivo .pdf. Eu também posso usar o visualizador que eu quiser para ver um certo formato de arquivo. Ao invés de kdvi, eu poderia especificar okular ou mesmo o evince (embora ele não inclua as imagens na visualização). E assim por diante. São variáveis para o usuário definir...

Que fique claro que um Makefile mais sofisticado teria colocar essas opções como argumentos, mas como eu disse, esse Makefile que eu escolhi é mais complexo que o básico e mais simples que o completo.

O bloco seguinte são as opções do programas

# Opções dos comandos {{{
############################ OPÇÕES DOS COMANDOS ##############################

# Opções do comando TEX especificado acima
OPTDVI = -halt-on-error
# Opções do comando dvips, que converte o arquivo .dvi para o .ps
OPTPS = -Z
# Opções do comando comando "pdflatex"
OPTPDF =
# Formato de conversão utilizado pelo ps2pdf (necessário especificar)
FORMATO = a4
# Estilos dos glossários, nomenclaturas, etc.
STYLENLS = nomencl.ist
STYLEGLS = nomencl.ist
# Opções do comando make
OPTMAKE = -s

# }}}

Se o usuário não conhece o comando, fica muito difícil dar palpites aqui. É necessário olhar o man de cada aplicativo para saber porque coloquei certas opções e para escolher outras. Afirmo que essas opções são agradáveis para 99 % dos usuários. Dois únicos cuidados são: definir o tamanho do papel para o ps2pdf e definir o estilo para o glossário e nomenclaturas. Note que eu usei o mesmo, mas há casos onde existe um estilo pré-definido e casos onde são diferentes os estilos.

Novamente, as opções padrões ficam no interior do Makefile, as alternativas deviam ser passadas por linha de comando, algo que eu não fiz intencionalmente... (quem sabe em uma versão futura)

Seguindo, encontramos mais variáveis.

# Outros programas {{{
############################# OUTROS PROGRAMAS ################################

# Comando que gera o índice, a nomenclatura, etc. Não existe outro atualmente
MAKEINDEX = makeindex
# Comando que gera a bibliografia, não existe outro atualmente
BIB = bibtex
# Conversão entre arquivo .ps e arquivo .pdf, existem outros, mas esse é o
# melhor para o GNU/Linux.
PSPDF = ps2pdf
# Eliminar arquivo. Não é razoável fazer de outra forma.
RM = rm -fv
# Comando make (até existem outros, mas não para esse Makefile).
MAKE = make

# }}}

Essas variáveis, são os outros comandos. Comandos no sistema que eu NÃO quero que sejam modificados. Quem gera o índice, e o makeindex, não existe outro. Quem gera a bibliografia é o bibtex, não existe outro.
Quem deleta arquivos é o rm. Bom, até existem outras formas de usá-lo, mas você quer mesmo modificar isso?

Da mesma forma, o make é o make. Até existem outros, como o colormake, mas fracamente, se é para usar um comando, use o mesmo que foi digitado, ou seja, se eu digito cmake, ele compilaria com o cmake, se eu digito make, ele compila com o make. Se entendeu a minha lógica, é melhor não modificar nesse comando até que consiga fazer o sincronismo entre o digitado pelo usuário e essa variável sem que o usuário deva especificar no interior.

Embora o autor (eu) não recomende modificá-las, essas variáveis são como quaisquer outras. Podem, sim, ser modificadas. O maior exemplo disso é o ps2pdf. Existem inúmeras formas de converter um arquivo .ps em um arquivo .pdf, mas apenas uma foi disponibilizada por mim, porque assim eu defini.

Execução
Passada a parte de configuração, vem a parte de execução.

Os primeiros comandos são preparações, eventualmente necessárias.

# Indentificação do nome do arquivo
DOC := $(shell egrep -l '^[^%]*\\begin\{document\}' *.tex |rev|cut -b5- |rev)

# Verificando se existe bibliografia

BIBFILE := $(shell egrep -l '^[^%]*\\bibliography\{' $(DOC).tex)

# Verifica se é uma apresentação do prosper
PROSPER := $(shell egrep -l '^[^%]*\\documentclass\[.*\]\{prosper\}' *.tex)


O primeiro comando define qual é o arquivo principal dentro do diretório em que ele é executado.
É um comando no shell. Ele gera a variável DOC, essa variável é utilizada como $(DOC) (se fosse um shellscript, seria $DOC, mas não é um shellscript, é um Makefile). De forma que $(DOC).tex é o arquivo principal da estrutra LaTeX (que pode conter vários documentos independentes).

Nesse ponto, vemos a primeira falha do autor. Ele não deixou claro, mas se existirem dois arquivo .tex com nomes diferentes contem um \begin{document} NÃO COMENTADO no mesmo diretório, haverá erro de compilação.

Porque o comando seguinte, verifica o arquivo $(DOC).tex procurando pela existência do comando que define se existe ou não uma bibliografia.

O terceiro comando é um daqueles casos de automação úteis. Oras, se o documento .tex for um código do prosper, então o DVI não faz sentido... logo, eu posso identificar esses casos e resolver o problema dele gerando sempre um PDF no final.

Relembrando as ações básicas

Gerar um $(DOC).dvi, gerar um $(DOC).pdf, limpar os arquivos intermediários, eliminar tudo que foi gerado pelo Makefile, inclusive o produto final e mostrar o resultado, tanto do dvi, quanto do pdf.

A ordem dos blocos não importa, exceto pelo primeiro bloco.

Bloco $(DOC).dvi, o primeiro bloco
# Gerando o "arquivo" DVI ...
$(DOC).dvi:
# mas ele é esperto o bastando para saber que não gera-se DVI com o pdflatex.
# E também gerará o PDF caso seja o proper seja utilizado.
@if [ ! -z $(PROSPER) ]; then \
$(MAKE) dvi; \
$(DVIPS) $(OPTPS) $(DOC).dvi; \
$(PSPDF) -sPAPERSIZE=$(FORMATO) $(DOC).ps $(DOC).pdf; \
elif [ $(TEX) == latex ]; then \
$(MAKE) dvi; \
elif [ $(TEX) == pdflatex ]; then \
$(MAKE) $(DOC).pdf; \
fi
Em teoria, esse bloco gera um arquivo DVI, mas ele DEVE ser esperto o bastante para saber que não se gera um DVI quando utiliza-se o pdflatex, e o serviço NUNCA para no DVI quando se está utilizando o prosper.

Mas o primeiro detalhe é o nome do bloco: $(DOC).dvi. O nome do bloco é o nome do suposto produto final. Isso é MUITO importante, porque evita que você compile novamente aquilo que já foi compilado, ou seja, se ao digitar "make $(DOC).dvi" no terminal o make encontrar o arquivo $(DOC).dvi, então ele para ali mesmo.

O segundo detalhe é posição do bloco dentro do código. Ele é o primeiro bloco, logo, ao digitar "make" sem argumentos, será ele que será executado.

Todos os comandos que compõem esse bloco estão afastados de um tab da margem esquerda.

O algorítimo é outro assunto, mas para melhor entendimento do Makefile, eu vou passar por esse bloco mais detalhadamente.

A primeira linha verifica se a variável $(PROSPER) não está vazia. Por que ela não está vazia, deve-se criar o DVI, converter esse DVI para o formato PS e depois converter o PS para o PDF. Porque não converter direto do DVI para o PDF ? Porque fica muito melhor assim de acordo com minha opinião. Um Makefile mais completo devia dar margem a outras opiniões. Caso $(TEX) seja igual a "latex" e não seja um arquivo prosper, então, eu quero gerar um dvi. Se $(TEX) for igual a pdflatex, então eu quero gerar um pdf diretamente. Por que isso foi feito ? Caso eu digite make no terminal, não é esse o bloco que será executado ? Então, se eu tiver selecionado pdflatex, eu certamente quero um pdf, eu não quero o DVI (porque o pdflatex não gera dvi :-0 ), logo crie o pdf. Melhor que uma mensagem de "erro" antipática (criada porquem escreveu o Makefile) que não lhe permita usar o make sem argumento diretamente no terminal.

O arroba na frente do if significa que eu não quero que o comando ecoe pelo terminal. Por padrão, o comando make funciona como se estivesse em permanente modo de debug. Mostrando quais são os comando que serão executados e executando-os. Eu não quero que ele escreva o comando na tela ? Então coloco o arroba na frente. O arroba na frente do if serve para todo o grupo de "uma única linha" do if.

Digo uma única linha, porque a barra invertida no final de cada linha significa que o comando continua na linha seguinte. O motivo pelo qual fiz isso no arquivo, é porque é mais fácil lidar com erros de formatos quando se utiliza a barra invertida (que deve ser o último caractere de uma certa linha).

Note os comandos no interior das condições.
    $(MAKE) dvi; \
ou então,
    $(MAKE) $(DOC).pdf; \
Esse comandos estão invocando o próprio make, que invoca um bloco dentro do Makefile. Um dos blocos chama-se "dvi" e o outro "$(DOC).pdf". Por similaridade com o "$(DOC).dvi", acredito que todos imagem o que seja o "$(DOC).pdf". Por sua vez, o bloco "dvi". É quem faz o serviço sujo. É ele quem de fato realiza o trabalho de compilar os código fonte gerando o resultado. Eu poderia dispensar esse bloco adicional, contudo, o código fica mais legível com ele, que faz um papel de subrotina ou função (como preferir).

Antes olhar o bloco que faz o serviço sujo. Vamos observar o bloco $(DOC).pdf

Bloco $(DOC).pdf
# Gera o arquivo PDF...
$(DOC).pdf:
# de um arquivo DVI, convertendo-o para PS e em seguida para PDF caso
# o comando padrão seja o latex ou diretamente, caso o comando padrão seja
# o pdflatex.
# Também diminuimos o esforço caso o prosper esteja sendo usado.
@if [ ! -z $(PROSPER) ]; then \
$(MAKE) $(DOC).dvi; \
elif [ $(TEX) = latex ]; then \
$(MAKE) $(DOC).dvi; \
$(DVIPS) $(OPTPS) $(DOC).dvi; \
$(PSPDF) -sPAPERSIZE=$(FORMATO) $(DOC).ps $(DOC).pdf; \
elif [ $(TEX) = pdflatex ]; then \
$(MAKE) pdflatex; \
fi
Primeiro, ele verifica se é um arquivo prosper e caso seja, passa ao bloco $(DOC).dvi o dever de cuidar desse caso. Se $(TEX) for igual a "latex", então primeiro deve-se gerar um DVI e sem seguida converter para ps e por fim, converter para pdf. Nesse ponto nota-se claramente a vantagem de ter o bloco com o nome $(DOC).dvi. Caso o DVI exista, ele não será recriado. Caso $(TEX) seja pdflatex, então chame o comando "$(MAKE) pdflatex", ou seja, o originalíssimo nome de bloco igual a "pdflatex" para a criar um pdf com o "pdflatex".

Bloco dvi

Aquele que faz o serviço sujo. Ele é idêntico ao bloco "pdflatex". O único motivo para os dois blocos existirem é porque assim eu defini. Até as opções, que são diferentes variáveis para cada comando, não justifica tal escolha. Primeiro porque eu poderia usar um if para gerar diferentes opções para cada comando, segundo porque as opções do comando latex são iguais as do comando pdflatex.

E porque defini dois blocos ? Porque eu estava com pressa para assistir uma defesa de tese nesse dia e não percebi o que tinha escrito até que era tarde demais. Aí tive pouco tempo para modificar.

Reconheço e reafirmo a utilidade de existir o bloco dvi e o bloco pdflatex, assim como devia existir o bloco pdf. porque a intuição humana fará o usuário digitar "make dvi" ou "make pdflatex" ou "make pdf" e assim é muito bom sincronizar o código a intuição humana. Mas definitivamente, não precisa ser dois blocos grandes e idênticos.

Bom, o bloco dvi é dado abaixo
# Gerando o arquivo DVI com o latex
dvi:
# Compliação inicial do arquivo tex
$(TEX) $(OPTDVI) $(DOC).tex
# Se existe bibliografia ...
@if [ ! -z $(BIBFILE) ]; then\
$(BIB) $(DOC).aux; \
$(TEX) $(OPTDVI) $(DOC).tex; \
$(BIB) $(DOC).aux; \
$(TEX) $(OPTDVI) $(DOC).tex; \
fi
# Se existe glossário, nomenclatura ou indice...
@if [ -f "$(DOC).nlo" ]; then \
$(MAKEINDEX) $(DOC).nlo $(STYLENLS) -o $(DOC).nls; \
$(TEX) $(OPTDVI) $(DOC).tex; \
fi
@if [ -f "$(DOC).glo" ]; then \
$(MAKEINDEX) $(DOC).glo -s $(STYLEGLS) -o $(DOC).gls; \
$(TEX) $(OPTDVI) $(DOC).tex; \
fi
@if [ -f "$(DOC).nlo" ]; then \
$(MAKEINDEX) $(DOC).nlo $(STYLENLS) -o $(DOC).nls; \
$(TEX) $(OPTDVI) $(DOC).tex; \
fi
@if [ -f "$(DOC).glo" ]; then \
$(MAKEINDEX) $(DOC).glo -s $(STYLEGLS) -o $(DOC).gls; \
$(TEX) $(OPTDVI) $(DOC).tex; \
fi
@if [ -f "$(DOC).idx" ]; then \
$(MAKEINDEX) $(DOC).idx; \
$(TEX) $(OPTDVI) $(DOC).tex; \
$(MAKEINDEX) $(DOC).idx; \
$(TEX) $(OPTDVI) $(DOC).tex; \
fi
# Uma última vez apenas para confirmar que tudo está ok...
$(TEX) $(OPTDVI) $(DOC).tex
Observe que ele não passa de um bloco de comandos em lista para os quais são efetuadas operações adicionais caso exista bibliografia, glossário, nomenclatura e índice. Nada diferente do que faria se estivesse escrevendo um shellscript, ou seja, nada diferente do que faria se estivesse digitando tudo no terminal. Todos os comandos são repetidos pelo menos duas vezes para assegurar o sucesso de qualquer projeto, não importa o tamanho. Mas esse tipo de dica é latex/terminal/linux não Makefile. Caso venha a compilar o código fonte em c, teriamos algo como "$(GCC) $(GCC_FLAGS) $(CODE)" e seria apenas uma vez.

Blocos clean e cleanall

... ou melhor dizendo limpando o diretório. Os dois blocos são reponsáveis por eliminar os arquivos não mais desejados. O bloco clean limpa os arquivos intermediários (e como tem arquivos intermediários nesse caso). o bloco cleanall, elimina todos os arquivos, inclusive os resultados, ou seja, o pdf e o dvi gerado.
# Limpando o básico dos arquivos gerados pelo compilador
clean:
@$(RM) *.aux *.log
@$(RM) *.toc *.lot *.lof
@$(RM) *.ttt *.fff *.blg *.out
@$(RM) *.ind *.ilg *.idx *.aux *.glo
@$(RM) *.gls *.abx *.nlo *.syx *.nls
@$(RM) *.ps
@$(RM) *.tex.backup
@$(RM) *.bib.backup *.bib.bak
@$(RM) *.tex.bak
@$(RM) *.bbl
@$(RM) *.*~
@$(RM) Makefile~

# Limpando tudo, inclusive os arquivos finais.
cleanall:
$(MAKE) clean
@$(RM) *.dvi *.pdf
Detalhe interessante fica por conta de como o cleanall foi criado. Ele usa o bloco clean e depois elimina o que sobrou, que são os resultados. Essa é a forma elegante de aproveitar os comandos de um bloco em outro bloco.

Blocos de visualização

Quatro blocos adicionais foram criados para permitir visualizar o resultado: show e shownew, showpdf e shownewpdf.
show:
@if [ ! -z $(PROSPER) ]; then \
$(MAKE) $(DOC).dvi; \
$(PDFVIEW) $(DOC).pdf; \
elif [ $(TEX) == latex ]; then \
$(MAKE) $(DOC).dvi; \
$(DVIVIEW) $(DOC).dvi; \
elif [ $(TEX) == pdflatex ]; then \
$(MAKE) $(DOC).pdf; \
$(PDFVIEW) $(DOC).pdf; \
fi

# Idem ao "show", a diferença é que aqui
# é feito uma nova compilação, de um jeito ou de outro
shownew:
$(MAKE) cleanall
@if [ ! -z $(PROSPER) ]; then \
$(MAKE) $(DOC).dvi; \
$(PDFVIEW) $(DOC).pdf; \
elif [ $(TEX) == latex ]; then \
$(MAKE) $(DOC).dvi; \
$(DVIVIEW) $(DOC).dvi; \
elif [ $(TEX) == pdflatex ]; then \
$(MAKE) $(DOC).pdf; \
$(PDFVIEW) $(DOC).pdf; \
fi

# Idem ao "show", mas para arquivos PDF apenas
showpdf:
$(MAKE) $(DOC).pdf
$(PDFVIEW) $(DOC).pdf

# Idem ao "shownew", mas para arquivos PDF apenas
shownewpdf:
$(MAKE) cleanall
$(MAKE) $(DOC).pdf
$(PDFVIEW) $(DOC).pdf

# }}}
Nesse ponto, espero que tenham compreendido o suficiente do código para compreender o que foi feito. Pois o objetivo é visualizar o arquivo. Se for um DVI abrir o visualizador de DVI, se for um PDF abrir um visualizador de pdf, caso não exista o arquivo, crie-o.

Os blocos com "new" no nome, são assim definidas porque eliminam o pdf/dvi que eventualmente exista, compila novamente e exibe o novo arquivo.

Os blocos com "pdf" no nome, força que seja visualizado o pdf, não importa qual o processo que o gera. Os demais vão exibir o DVI sempre que esse for válido/existir ou o PDF, em contrário.

Finalizando

O último bloco (que eu não vou transcrever para esse ponto) é o bloco help, que permite que o usuário digite "make help" para descobrir quais são os comandos diponíveis.

Conclusão
Esse texto ficou longo demais. Então vou ser breve.

Falta discutir alguns pontos e abordar um Makefile para programação em si (ou seja, para arquivo C/C++/Fortran). Assim como algumas normas de etiqueta para esses tipos de Makefile. Entenda: existem nomes de variáveis que são reconhecidos por qualquer programador no mundo, como GCC_FLAGS, porque usá-las ou não usá-las. E finalmente discutir porque usar o Makefile e não um shellscript. Existem fatores que induzem a usar o Makefile, mas se é apenas para você, porque usar o make ? Mas não prometo a terceira parte para logo...

Uma quarta parte agendada para daqui a muito (muito mesmo) tempo, seria como lidar de forma correta com as opções dentro do Makefile. Esse é o ponto mais delicado e complexo e daria um ar profissional ao Makefile (como os dos grandes programas). Mas é também o que dá mais trabalho, portanto, exige planejamento e detalhamento ... e tempo para escrever.