quarta-feira, 31 de dezembro de 2008

Desenho do Tux, o Mascote do Linux

O Tux é aquele simpático piguim, mascote do Linux. Não consigo imaginar qualquer programa ou sistema em todo o mundo que tenha um mascote tão famoso e admirado como o Tux. Assim, para divertir os camaradas leitores, estou postando uma série de fotos e links de galerias, onde é possível encontrar o Tux incorporando os mais diversos personagens...

  • Detalhes Históricos
O Tux foi criado por Larry Ewing durante a lista de discussões do Kernel do Linux, em 1996, a partir de uma sugestão inicial de Alan Cox e posteriores sugestões do próprio Linus Torvalds, o criador do Linux. Conta-se que Linus estava visitando a cidade australiana de Canberra, quando (talvez num zoológico) teria sido mordido acidentalmente por um pinguim. Como já alegava paixão por aves marinhas gordas que não voam, não teve dúvida: o mascote seria um pinguim gordinho, feliz e simpático!! Mais detalhes, vide aqui.

Ache as imagens oficiais aqui, incluindo uma versão em postscript.
Curiosidade: apesar de poucos saberem, existe uma espécie de pinguim que voa!! Veja o vídeo aqui!!

Aqui seguem algumas fotos do Tux:

Rasta Tux
Baby Tux

Tux Skywalker


WolfeTux

Tux Croft

Tux Sparrow

Tuxtaruga Ninja

Tux Naruto

Pink Tux, para as meninas!!

Se você está se divertindo, veja a infinidade de personagens do Tux, desde Mestre Yoda até Charles Chaplin, passando por Super Man, Super Mario, C3PO e até Coca-Cola (!!) nas galerias abaixo:

http://www.junauza.com/2008/03/30-coolest-and-funniest-tux-icons.html
http://linux.meuhobby.com/index.php?pag=galeriatux.html
http://www.gnu.org/graphics/3dbabygnutux.html
http://tux.crystalxp.net/en.id.1763-fcys14-tux-rasta-bob.html
http://stoa.usp.br/gnusp/files/306


Beleza, pessoal!! Boa diversão!!

terça-feira, 30 de dezembro de 2008

Como recuperar partição Reiserfs com bad blocks?

Este é um assunto interessante: às vezes, tudo está bem com seu sistema... está tudo configurado, rodando, indo às mil maravilhas!! Porém, ninguém escapa do infortúnio de um defeito físico no disco rígido, não é mesmo?? E ele é como aquelas visitas mensais de sua namorada ou esposa: vem sempre no pior e mais inesperado momento, sem aviso, e te pega num golpe baixo, onde você terá de ser hábil para não por tudo a perder...
Daí você se lembra das recomendações do Pajé descritas neste artigo, e fica tranquilo, pois ainda há luz no fim do túnel!!

  • Do que Trata Este Artigo?

Apesar de ser destinado àqueles que utilizam partições com sistema de arquivos ReiserFS, as recomendações aqui descritas podem ser parcialmente aplicadas a problemas com outras partições.

  • Quais os Sintomas, Doutor?

O computador está trabalhando bem mas, de repente, você obtém uma mensagem de algum aplicativo dizendo que houve erro de entrada e saída (I/O, o famoso Input/output error). Isto pode acontecer a qualquer momento: durante o uso ou mesmo durante a inicialização do sistema.

  • O Que Fazer Agora?

A primeira dica é a mais importante de todas:
  1. Se você está trabalhando, interrompa tudo o que você está fazendo e salve todos os seus trabalhos, desligando o micro em seguida. Se estava apenas utilizando o micro, desligue-o imediatamente. Isto é o mais importante porque evita que você perca seus dados. Erros de Input/output podem provocar que programas inteiros travem e/ou fechem, e você não gostará de se encontrar trabalhando quando, inadivertidamente, tudo travar durante alguns minutos e fechar repentinamente.
  2. Pegue um CD de resgate de sua distribuição. Pode ser um CD do Kurumin, do Ubuntu, do SuSE ou de qualquer outra distribuição que tenha as ferramentas de seu sistema de arquivos (no nosso caso, o ReiserFS), e que seja capaz de iniciar pelo CD, ao menos em modo texto. Acredite se quiser, existem distribuições de Linux especializadas nisto, pequenas o suficiente para iniciar facilmente pelo CD e contendo, todavia, milhares de ferramentas de recuperação. Acredito ser interessante citar o SystemRescueCD.
  3. Se você conseguir, monte a sua partição como somente leitura e faça backup de todos os seus dados pessoais e arquivos de configuração. Só isto já é um alívio! Pode ser para CD, DVD, Pen Drive, Fita, outra partição (se no mesmo disco, desaconselhável...), o que for... mas faça o backup. Não esqueça as tabelas do MySQL, aqueles arquivos que você cisma em colocar no /tmp, apesar de não ser recomendado, e os favoritos do Firefox.

  • Copiando a Partição com o dd
Se a coisa ficou realmente feia e você sente aquele frio na espinha, lembre-se de que você pode criar uma imagem de sua partição, lendo o que for possível, e tentar recuperar depois com as ferramentas do Reiser. Use esta técnica se você notar que a partição defeituosa não monta, mesmo que somente leitura, ou monta mas não lê devido a milhares de erros de leitura. Siga estes passos:
  1. Crie, em outro disco, preferencialmente, outra partição com o mesmo tamanho da partição defeituosa;
  2. Copie bit a bit a partição defeituosa para a recém-criada, com o comando dd abaixo:
# dd if=/dev/hda1 of=/dev/hdb1 bs=4k conv=noerror,sync

Explicando o comando:
if-> partição defeituosa, usada como entrada de dados. No nosso caso, o /dev/hda1 (não é /mnt/hda1!!!!);
of -> partição de destino, preferencialmente em outro HD, já que o primeiro não tem mais a nossa confiança...
bs -> é o tamanho do bloco de leitura do dd ("block size"). Lembre-se de que, quanto menor o tamanho, maior a precisão da leitura, permitindo recuperar mais dados. No entanto, quanto menor o tamanho, mais chances de se esbarrar e setores ruins e mais lenta será a recuperação (experimente bs=1024 e veja que lerdeza não será este procedimento...). Acredito que você deva começar com um tamanho otimista, pequeno, como o sugerido e, se a leitura se tornar insuportavelmente lenta, aumente o tamanho. Você poderá perder mais informações, mas vai pular muito mais setores ruins, fazendo a cópia bem mais rápido. Dica: não seja tão radical aqui. Você vai perder alguma coisa, mas o importante é recuperar a maioria dos dados.
conv -> Estas opções acima foçam que, havendo erro de leitura, o bloco será pulado e, em seu lugar, na partição de destino, será gravado um bloco com bytes zerados. Esta é uma maneira de remediar o irremediável: pula-se o que não será lido mesmo e ganha-se tempo.

Se seus dados são realmente muito importantes e você tem que garantir a cópia fiel do máximo possível deles, custe o que custar, então utilize este comando:

# dd_rescue /dev/hda1 /dev/hdb1

O comando dd_rescue acima é mais eficiente que o dd, nesta conjuntura. Ele lê blocos maiores, de 64kB, porém apenas quando a leitura funciona. Se houver erro de leitura, o bloco gigantesco de 64kB é quebrado em frações mínimas de 512 bytes, onde será lido e gravado o que for possível. Assim, você terá um desempenho maior para setores sem defeitos (64kB vai, a passos largos, mais rápido que 4kB) e, todavia, garante que, nos lugares problemáticos da superfície de seu disco, a leitura tentará ser tão detalhada quanto possível, ainda que tome muito tempo. Uma alternativa mista, ainda, é o dd_rhelp, que roda o dd_rescue várias vezes, procurando balancear entre a perda de tempo e a eficiência de recuperação de dados.

Verifique mais informações:
na página do dd_rescue:
http://www.garloff.de/kurt/linux/ddrescue/
na página do dd_rhelp:
http://www.kalysto.org/utilities/dd_rhelp/index.en.html

  • Recuperando a Partição
E agora, o que temos?? Bom, temos uma imagem da partição defeituosa, feita com alguns problemas durante a cópia, porém escrita sobre um disco de superfície perfeita, intacta, funcional e límpida como a aurora orvalhada da primavera... basta, então, tentar recuperar o possível.

  1. Com a partição desmontada, rode o tradicional: reiserfsck --check /dev/hda1.
  2. Provavelmente não funcionará, mas não se desespere... agora você não tem setores ruins, apenas seus dados não foram bem gravados. Então, vamos pedir ao sistema que reconstrua a sua árvore com a estrutura de seus dados, para poder montar e usar sua partição:
reiserfsck --rebuild-tree /dev/hda1

Como não há setores ruins, as chances de a reconstrução da árvore parar no meio são pequenas. Terminado com sucesso este comando, possivelmente sua nova partição estará saudável e poderá, pelo menos, ser lida para a recuperação dos seus preciosos dados, antes perdidos dentro dela...
Atenção: o rebuild-tree pode demorar para terminar. Nunca o interrompa, a fim de evitar danos à sua partição. Se ele parar com erro, rode-o de novo imediatamente.

(*) Lembre-se de substituir "/dev/hda1" pela partição correspondente!!

  • Casos Omissos

Se desejar ou necessitar recuperar a partição original, a qualquer custo, sem a chance de fazer a cópia descrita acima, então é preciso se gerar uma lista com todos os setores ruins (um arquivo com o número de cada setor ruim, um por linha) e rodar o comando:

reiserfsck --rebuild-tree --badblocks ./file /dev/hda1

Onde ./file é o arquivo com os setores ruins. Este arquivo pode ser gerado automaticamente (vide instruções na referência "dica", abaixo, e no item seguinte) ou manualmente, tentado rodar e repetir o comando a cada novo setor ruim encontrado e acrescentando o novo setor ruim no arquivo (só faça isto em último caso, a não ser que você queira levar semanas nesta operação!!). Se for preciso mesmo, tente gerar este arquivo automaticamente (vide item abaixo). Como esta técnica foge ao escopo deste artigo, incluí uma referência (abaixo) com todas as instruções para a sua realização, a fim de não deixar nenhum caro leitor na mão...

Dicas: tudo sobre como lidar com bad blocks e recuperação de sistemas de arquivos ReiserFS, clique aqui.

  • Outros Comandos
badblocks -o badbk.txt -v /dev/hda1: Verifica blocos ruins em uma partição e os grava no arquivo "badbk.txt". Útil no caso citado anteriormente. A opção "-v" permite ligar o modo verbose, que mostra alguma coisa na tela sobre o progresso da operação, ao invés do cursor piscando monotonamente. O arquivo gerado pode servir de input para várias ferramentas de recuperação de partições. No caso do Reiser, poderá servir para o comando do item anterior (reiserfsck).
Importante: o comando badblocks utiliza, por padrão, o tamanho de bloco de 1024 bytes. Contudo, a maioria das partições contróem blocos, por padrão, de 4096 bytes (4kB), e este é o padrão das partições Reiser. Se você coletar os dados com o tamanho errado, sua ferramenta de recuperação vai recusar o arquivo de blocos ruins gerado. Uma maneira de contornar este problema é informar ao comando badblocks o tamanho esperado de bloco de sua partição defeituosa, com o parâmetro "-b", da seguinte maneira:

badblocks -o badblocks.txt -vs -b 4096 /dev/hda1



Espero ter ajudado!! Gostou?? Detestou?? Ajudou?? Só te atrapalhou?? COMENTE!!

segunda-feira, 22 de dezembro de 2008

O Futuro do Java

Estive nestes últimos dias entretido com o(s) artigo(s) de capa da revista Mundo Java, onde diversos especialistas e pessoas notórias arriscam suas idéias sobre o futuro e as tendências do Java no mercado. Não posso negar que é um excelente apanhado de opiniões, varrendo as principais tecnologias Java, desde Javacard e J2ME até SOA e desenvolvimento orientado a serviços, trazendo as mais recentes novidades de cada área.
No entanto, uma coisa me parece que fugiu aos assuntos da revista, e por isto resolvi discriminá-la aqui, pois também me parece uma tendência que tem se fortalecido aos poucos e tem ganhado muito fôlego: a programação gráfica. O que vem a ser isto?? Bom, é mais um termo pajetiano para algo que está surgindo devagarinho e tende a ganhar grande impulso!
Programação Gráfica é todo o tipo de geração de código feito indiretamente, através de uma ferramenta gráfica; ou seja, ao invés de o programador escrever seu código, comando a comando, linha a linha, ele abre mão de uma IDE sofisticada onde, a partir de componentes iconográficos, pode arrastar objetos, definir suas propriedades, configurações, relacioná-las umas com as outras (meio que como se montasse um diagrama) e a ferramenta, dando-se por satisfeita com as informações prestadas, gerará automaticamente o código correspondente, podendo vir a compilá-lo e executá-lo, caso necessário.
Para quem programa em Java, isto há muito não é novidade... o Netbeans, por exemplo, gera dezenas de linhas de código em Swing automaticamente, a partir de uma interface amigável facilmente configurada (ou melhor, "desenhada") pelo programadores. Para quem usa o Eclipse, um bom plugin de funcionalidades semelhantes seria o Visual Editor Project (que inclusive suporta SWT), ou o Jigloo, que também tem versão para o Websphere Studio. Estes plugins não se limitam somente à interface gráfica, mas também comportam tratamento de eventos, dentre outras funcionalidades sofisticadas, costumeiramente desenvolvidas apenas via códigos e linhas intermináveis.
Para quem acha que isto só existe para interfaces gráficas de programas locais, aconselho que invista algum tempo examinando a sofisticação deste plugin: GWTDesigner, que faz exatamente a mesma coisa, porém para o desenvolvimento web com o Google Web Toolkit.
Bom, parece que a era da programação exclusivamente via texto realmente está no fim, e uma grande transformação está por vir!! Para quem ainda não acredita, vou deixar soar as trovoadas, citando rapidamente apenas mais uma ferramenta que veio para derrubar qualquer opinião contrária: o JasperETL, uma IDE de programação de manipulação de arquivos construída a partir do Eclipse, pelo time da Jaspersoft (o mesmo que mantém o Jasper Reports e o iReports), gratuita e disponível para qualquer plataforma. O JasperETL é uma IDE de programação diferente: nela você não escreve código, apenas arrasta os componentes para o diagrama central e os relaciona com ligações pertinentes (Iterator, para laços, etc...), configurando o fluxo do programa e todas as propriedade desejadas. Ao passo em que você faz isto, ele gera automaticamente o código. Também compila, coloca breakpoints, roda, inspeciona, etc, como o Eclipse faria normalmente.
O objetivo do JasperETL é ser uma IDE completa de geração relâmpago de programas processadores de arquivos. Ela suporta arquivos em diferentes dispositivos, faz acesso a banco de dados, lê e valida XML contra Schemas, extrai dados dos XMLs, converte nos mais diferentes formatos (gera até planilha do Excel!), é capaz de tomar decisões e modificar o fluxo, etc... tudo programado apenas num "simples" diagrama gráfico. Com o JasperETL, é possível fazer programas sofisticados que demorariam semanas em apenas 1 dia, e sem risco de erros.
Explorando a idéia da geração automática de código a partir de uma ferramenta gráfica, sob um prisma bem mais conhecido, pode-se citar ainda dezenas de programas para criação de diagramas UML, como o editor gratuito JUDE Community, que são também versáteis geradores de códigos a partir de seus diagramas (e vice-versa!). Com eles, você gera um diagrama de classes em UML 2.0, por exemplo, e o programa é capaz de interpretá-lo e criar as classes correspondentes, automatizando este penoso e braçal ofício.
Com este artigo, procurei mostrar uma tendência do Java, como também do mercado e do desenvolvimento em geral: a invasão de ferramentas e super bibliotecas de automatização de código, configuradas e manipuladas graficamente. Acredito que esta é uma tendência séria e que, ao logo dos próximos anos, vai modificar em muito a nossa maneira de produzir software. O pessoal do Mundo Java me desculpe, mas isto ficou faltando e não poderia ser deixado de lado...
Concorda, discorda?? Comente!!