Arquivo

Posts Tagged ‘computadores’

Revolução do grafeno dá mais um passo

quinta-feira, 30 abr 2009; \18\UTC\UTC\k 18 1 comentário

Fotografia obtida por microscópico eletrônico de varredura do circuito integrado nanométrico construido a base de grafeno. As barras amarelas são eletrodos de cromo e ouro e sobre a superfície azul ligando os eletrodos há uma fina camada de grafeno.

Fotografia obtida por microscópico eletrônico de varredura do circuito integrado nanométrico construido a base de grafeno. As barras amarelas são eletrodos de cromo e ouro e sobre a superfície azul ligando os eletrodos há uma fina camada de grafeno. Figura do artigo original de R. Sordan et al.

Físicos na Itália desenvolveram o primeiro circuito integrado de grafeno, o relatório foi publicado semana passada no arxiv.

O grafeno é um nanomaterial descoberto em 2004 que consiste em uma folha bidimensional de átomos de carbono de apenas um único átomo de espessura (uma fatia atômica de grafite). Ele difere dos demais materiais semicondutores — que são os materiais com as propriedades eletrônicas adequadas para construção de diodos e transitores — por manter alta mobilidade dos elétrons mesmo quando dopado com alta densidade de impurezas. Isso reflete em uma resistência a corrente elétrica que está entre as mais baixas já encontradas em um material a temperatura e pressão atmosférica, tornando o grafeno uma potencial matéria-prima para construção de circuitos integrados de alta freqüência (acima de GHz) em escalas micrométricas de tamanho, o que pode vir a substituir a presente tecnologia dos semicondutores de silício utilizados nos computadores e eletrônicos modernos. O trabalho do grupo italiano é um passo importante nessa direção porque demonstra que estes circuitos são factíveis. Em 2007, um grupo de Harvard já havia construído o primeiro transistor de grafeno.

Para saber mais:

  1. Fledgling graphene circuit performs basic logic, Physics World.
  2. Graphene na Wikipedia.

Edição colaborativa em TeX…

domingo, 12 out 2008; \41\UTC\UTC\k 41 8 comentários

Muita gente, mais cedo ou mais tarde, acaba trombando nesse problema: como editar colaborativamente um artigo científico, em geral editado em \TeX e \LaTeX?

Imagine a seguinte situação: vc numa sala, no seu depto preferido, e seu colaborador na sala ao lado! Como é que vcs podem se coordenar para escrever um artigo juntos? Agora, imaginem uma situação mais idealizada, só pra facilitar o argumento a seguir: vc e seu colaborador estão a meio planeta de distância. 😈

No meio científico, essa situação é razoavelmente comum: vários autores colaborando num mesmo artigo, um em cada canto desse nosso mundo redondo.

Praqueles que não têm uma necessidade tipográfica muito grande, algo como Google Docs dá conta do recado: vc simplesmente transfere sua ferramenta editorial para “the cloud“. 😉

Agora, pra quem tem necessidades tipográficas mais agudas — e.g., TeX, LaTeX, DocBook ou HTML —, a colaboração é certamente mais complicada e delicada.

As primeiras alternativas que surgiram foram as seguintes:

Quem usa Emacs pode utilizar AUCTeX e psvn.el para integrar tudo de modo suficientemente transparente.

Uma alternativa um pouco mais moderna, que integra e faz o papel de agregar as funcionalidades de “editor de textos” e “controle de versões”, é a seguinte:

  • Gobby (roda em qualquer plataforma: Microsoft Windows, Mac OS X, GNU/Linux e *NIX afins);
  • SubEthaEdit (só para Mac OS X).

Essencialmente, ambos são equivalentes: O Gobby é uma implementação “software livre” do SubEthaEdit. Para usuários menos experientes em lidar com o controle de versões, delegar essa tarefa diretamente para o editor pode ser uma saída viável. Para maiores informações sobre esse tipo de editores, é só dar uma olhada em Collaborative real-time editor. Infelizmente, eu não sei quantos desses têm suporte para TeX ou LaTeX.

Isso tudo posto… aautgora é hora de falar no Git: o Git é um dos softwares para controle de versão mais rápidos disponível atualmente. Aliás, mais do que isso, o paradigma descentralizado e distribuído do git o torna um candidato natural para um sistema de arquivos com as mesmas propriedades: o jeito mais fácil de entender o conceito do git é imaginar que vc pode, e.g., ter uma pasta no seu computador ‘replicada’ em outros computadores (que vc explicitamente permitiu acessar a pasta original): ou seja, todos os seus colaboradores vão ter acesso à mesma pasta, de tal forma que quando qualquer arquivo (formatos ASCII ou binários, i.e., TeX, LaTeX, DOC(X), PDF, JPEG, TXT, HTML, RTF, etc) dentro dessa pasta for atualizado, todos os colaboradores recebem essa mesma atualização!

Fora isso, o git tem algumas outras propriedades bem interessantes para quem está desenvolvendo uma colaboração científica, que tende a ser um processo altamente emaranhado e não-linear: suporte para desenvolvimento não-linear (resolução de conflitos de edição), desenvolvimento distribuído, é possível usar subversion através de comandos de compatibilidade, velocidade e escalabilidade (eficiência para grandes projetos), autenticação criptografada, entre outras.

Ou seja, através do uso do git o controle de versões é extremamente mais poderoso e flexível, isso pra não falar na resolução de conflitos, i.e., quando dois ou mais dos seus colaboradores estiver trabalhando no artigo (ou gráfico, imagem, etc — qualquer tipo de arquivo), ao mesmo tempo, qual modificação tem maior prioridade? O git é excelente nesse departamento… além de permitir que vc compartilhe toda uma pasta com seus colaboradores, uma vez que qualquer tipo de arquivo é monitorado e atualizado automaticamente.

É, a meu ver, a saída mais sofisticada e robusta para o problema de colaboração e acesso de várias pessoas a um mesmo conjunto de arquivos (e tudo pode funcionar de modo encriptado, o que torna todo o processo ainda mais confortável). Porém, infelizmente, ainda não há nenhum suporte para git no Emacs nem em nenhum outro editor que eu conheço. Mas, dado que o AUCTeX é uma ferramenta tão poderosa, vale a pena se ajustar ao meio termo: “Emacs + AUCTeX” e Git no console. Pode ser meio confuso no começo, mas uma vez que se acostuma com esse arranjo… é puro zen! 😎

O que me traz à terceira opção: Dropbox (leiam mais no link Tour).

Essencialmente, o Dropbox é uma versão mais “user-friendly”, amigável, de softwares de controle de versões: o processo de instalação cria uma pasta no seu computador que fica arquivada no cloud deles… e, dessa forma, toda vez que qualquer arquivo denro dessa pasta for modificado, as diferenças são propagadas para o cloud, onde ficam arquivadas também. E é agora que vem o pulo-do-gato: uma das sub-pastas (dentro da pasta-mãe, compartilhada via o serviço do Dropbox) é chamada Public, de modo que qualquer arquivo dentro dessa pasta pode ser acessado por quem tiver o respectivo acesso permitido.

Até aqui, tudo soa exatamente como no git, acima… a diferença crucial é que o Dropbox não usa o git como ‘backend’, i.e., o Dropbox tem seu próprio método de atualização dos arquivos — que, até agora, não é muito bem conhecido publicamente.

Portanto, nesse sentido, o Dropbox é uma espécie de git light, i.e., é uma versão mais levinha e com menos recursos do que o git — não tão robusto, mas que satisfaz as necessidades da grande maioria dos usuários.

A grande vantagem é que não é preciso que “alguém” instale um servidor rodando git, o que torna tudo muito mais acessível a qualquer nível de usuários. 😉

Então, no final das contas, essa não é uma saída tão ruim assim… perde-se uns recursos dum lado, mas ganha-se em manutenção do outro — em geral, é um bom meio termo. E, de quebra, ainda é possível se usar TrueCrypt para se encriptar o conteúdo de toda a pasta, tornando tudo muito mais seguro (mesmo que o conteúdo da pasta esteja na ‘cloud’, ele estará encriptado 😉 ).


Pessoalmente, meu sonho de consumo seria um servidor rodando uma combinação dos seguintes:

juntamente com todo o indexamento feito pelo SPIRES! E, a essa mistura, adicionaria-se um servidor git, para que todos os usuários pudessem colaborar livremente e, de modo completamente transparente, publicar o artigo assim que acabado!

Dessa forma, numa mesma e única plataforma estariam centralizadas as melhores e mais robustas funcionalidades disponíveis no momento — seria o paraíso! 🙂

Bom… é isso aí: a diversão é mais-do-que-garantida, []’s! 😈

Um pouquinho de Linux e o valor de “listas”…

sábado, 11 out 2008; \41\UTC\UTC\k 41 Deixe um comentário

Essa é rapidinha, só pra ressaltar dois links interessantes que apareceram nessa semana:

O primeiro link acima é sobre o projeto APTonCD, que faz um repositório dos pacotes duma distribuição baseada no apt (e.g., Debian ou Ubuntu) num CD ou DVD. Dessa forma é possível se carregar pra todo lugar os seus pacotes preferidos. 😉

O segundo link é um resumão com as melhores dicas do Shell-fu colocadas dentro dum único .bashrc.

E, pra quem gosta de “listas disso” e “listas daquilo”, acho que esse artigo vem bem a calhar:

Qual é a informação que realmente tem significado em listas e rankings? Mesmo que os dados sejam estatisticamente significativos, o modo como eles são comparados relativamente (i.e., os pesos atribuídos) tende a ser arbitrário, o que afeta o resultado final — às vezes, até alterando completamente as respostas obtidas.

Diversão garantida, []’s. 😈

Acesso Livre…

segunda-feira, 6 out 2008; \41\UTC\UTC\k 41 Deixe um comentário

Hoje em dia, o movimento que visa o acesso livre vai de vento-em-popa e já praticamente dispensa apresentações; principalmente no Brasil, onde a CAPES já até desenvolveu o famoso Portal de Acesso Livre.

Porém, o que muitos não sabem é a história de como tudo isso começou, em meados de 1991, quando Paul Ginsparg (sim, aquele já conhecido pelos férmions de Ginsparg-Wilson) deu início aos arXivs.

A entrevista abaixo é uma das poucas que o Ginsparg já deu, e é excelente, recheadas de ‘causos’:

É importantíssimo também lembrar que sem o TeX, dado de presente e mão beijada para o mundo todo pelo Don Knuth, nada disso teria sido possível — o TeX é uma das primeiras linguagens de markup.

Outro ingrediente importante foi a criação da WWW por Tim Berners-Lee. Como o próprio Ginsparg conta na entrevista, TBL o contactou pessoalmente… e assim os arXivs foram levados dum servidor de FTP para um de WWW… e assim surgiu o primeiro, ❗ , servidor da web no mundo!


N.B.: o servidor da HET Brown foi um dos primeiros também (se não me engano, foi o terceiro), logo em seguida dos arXivs: foi um dos meus predecessores (chamado Stephen Hahn) que o instalou, na sala de número 625 no prédio chamado Barus & Holley, e até pouco tempo atrás (quando eu atualizei e reconfigurei tudo pra rodar via Apache 2.0.63), tudo rodava naquele mesmo servidor original (um verdadeiro rinoceronte 🙂 )! Enquanto isso, no Brasil, o DFMA teve uma das primeiras páginas da USP, assim como o Ciências Moleculares, que certamente foi a primeira página sobre um curso de bacharelado da USP (quiçá do Brasil — ainda me lembro do dia em que instalei o primeiro servidor HTTP no servidor do CM, ainda chamado lnx00, e começamos a brincar com HTML)! Foi nessa mesma época que nasceu o Projeto Sócrates, do qual tive a sorte de participar (mas essa é outra estória).


Bom, essa é a história do Acesso Livre, não só no mundo, mas no Brasil também… que, como vcs vêm, tem tido uma participação bem sólida nisso tudo. 🙂

[]’s.

%d blogueiros gostam disto: