Depois quando eu digo que estamos lendo só merda na internet ainda dizem que sou chato…
Faz muito tempo que não falo aqui sobre jogos, mas, nem por isso parei de jogar e de me divertir com meu Playstation 2. Games para PC nunca me atraíram muito, mas sempre tive a sorte de ter algum bom console conectado à TV da sala.
Fiz uma pausa e vim aqui falar sobre o excelente Odin Sphere da Vanillaware/Atlus, um RPG lançado em 2007 e que, diziam, era o último grande game para PS2.
Este jogo me conquistou por diversos motivos e o principal deles é a narrativa belissimamente desenvolvida pelo diretor George Kamitani. Segundo ele mesmo, a intenção era fazer um jogo que seguisse uma veia shakespeariana, repleto de diálogos dignos de um (bom) livro, com linguajar moderno e, mesmo assim, elegante. Logo nas primeiras linhas nota-se algo a mais durante os diálogos. Os textos, quase como poesias, são declamados por uma dublagem excelente, de inglês claro, bem marcado e bonito.
Não se preocupe se você não gosta de ler; o jogo tem um fundo de mitologia nórdica misturada a outros elementos que tornam a trama atraente também para aqueles que gostam de partir logo para a porrada, mas a graça, na minha opinião, é desfrutar mesmo a história.
São 5 personagens, cada um de um livro e você precisa passar pelos 5 livros para completar a jornada. As vidas de cada um dos 5 são 
conectadas porque, sendo de raças diferentes e no meio de uma guerra, cada um deles luta para garantir a sobrevivência de seu povo. Dessa forma, jogando, você tem a oportunidade de observar a trama sob todos os pontos de vista, o de quem ataca, o de quem é atacado, o de quem vence, o de quem é vencido e se pega refletindo que não há, realmente, bons ou maus; apenas há povos lutando para alcançar um fim. Nas opções do jogo existe uma timeline que mostra como cada evento estava conectado.
Gráficos em 2D super coloridos e com traços bonitos, mas estilizados, lembrando pinturas em aquarela permitem que você se deixe levar pelas luzes e detalhes em cada cenário. Você vai enfrentar espectros de lava na terra do fogo, ietis raivosos nas montanhas geladas e atravessar netherworld, o submundo dos mortos em meio a espíritos rancorosos e cheios de cinismo, tudo isso empunhado a sua Scypher, que é uma arma forjada a partir das joias roubadas diretamente dos domínios da morte (legal, não?). Enquanto luta, as músicas orquestradas, composições da produtora de som Basiscape dão um bom suporte para completar a trama, mas, sinceramente, poderiam ser melhores, pois ficam meio repetitivas se você prestar atenção.
Não se trata de um jogo fácil: certos mestres chegam mesmo a irritar se por acaso forem enfrentados sem a preparação adequada, contudo, não chega a ser um jogo extremamente longo, podendo ser terminado em menos de 15 horas com algum esforço.
A maior reclamação, sinceramente, é técnica, pois, na hora em que a tela fica repleta de raios, explosões e monstros vorazes o hardware do PS2 começa a pipocar para o odiado efeito slowdown… se você não for esperto acaba morrendo para ter que começar o cenário de novo.
O game é, apesar desse defeitinho, uma verdadeira obra de arte, repleto de bom gosto, bem feito e muito interessante, ghegando a garantir um 8.8 no score da IGN.
Minha recomendação? Se você não jogou, jogue, pois este é um jogo memorável.
Faz algum tempo que alguns amigos e eu iniciamos um projeto chamado “Mosaicum”. A idéia por trás do Mosaicum é criar um ambiente rico em informações consideradas interessantes, fomentar o debate e trazer para as pessoas um tipo de cultura menos pasteurizada e menos pobre.
Os assuntos abordados no site variam desde arte, poesia e música até matemática, química e física e há espaço para compartilhar dados como e-books, músicas e vídeos (desde que respeitando as 3 leis).
Como o projeto ainda está engatinhando, não houve trabalho na divulgação e nem nos convites para chamar novos autores, mas a intenção é reunir num só lugar, pessoas que gostem de escrever sobre os mais variados assuntos, com os mais variados gostos, desde que apresentem bons textos/vídeos/músicas/livros/pinturas/opiniões…
Mais novidades para breve e, se você se interessou, porque não se junta a nós?
Quando digo que não suporto o Twitter sei que muita gente discorda e deve me achar um cara retrógrado e “por fora”, mas, sinceramente, quanto mais o tempo passa, mais minha opinião sobre microblogging se consolida.
Não é apenas pelo fato de haver milhões de pessoas compartilhando com todo o mundo atos banais com os quais ninguém se importa, tampouco por limitar o, já pobre, pseudo-português das pessoas a 140 caracteres (criando outra variante bizarra do internetês), mas, sejamos diretos, o Twitter é apenas a versão 2.0 das revistas de fofoca.
Legal para empresas, legal para projetos e até para profissionais que desejam compartilhar suas rotinas de trabalho, o Twitter se vê explodindo mundo a fora repletos de Joões-Ninguém que acham relevante fazer que todos saibam que ele vai cortar as unhas do pé ou preparar o jantar, ou ir deitar.
Não gosto mesmo e a prova de quão tosco é, em geral, o microblogging é que já existe o gerador de Tweets: se você não tem nada para escrever, gere um tweet randômico e diga ao mundo quão vazio você é.
Seguem aí 5 tweets “aleatórios” para mostrar o nível do negócio.
- Meu namoro terminou. A fila vai ter que andar!
- O Twitter acabou com o meu tempo livre!
- já dizia Confucio: — conheça-te a ti mesmo antes de conhecer a si próprio…
- Se minha sogra só pudesse reclamar em 140 caracteres ela teria uma crise de abstinência de palavras
- Baixando episódios do #Lost para fazer uma maratona neste fim-de-semana.
E fica a minha pergunta: quem se importa?
É incrível a habilidade humana de estragar e subverter as coisas, mesmo a mais legal delas.
Confesso que, comparado a certas pessoas que são ícones da informática e da tecnologia no Brasil, sou relativamente novo nisso tudo, mas, já em 2001, quando criei minha primeira conta de e-mail no finado LigBR (alguém lembra?) essa coisa de escrever cartas digitais para qualquer pessoa do mundo me fascinou profundamente.
A ideia, pelo visto, fascinou mais gente: há estimativas de que em Agosto de 2008 existiam 1,3 bilhão de usuários de e-mail e que 210 bilhões de mensagens eletrônicas são enviadas por dia em todo o mundo1. O problema é que, estatisticamente, quanto mais cresce o número de usuários, também aumenta o número de imbecis e dessa forma o spam surgiu, abocanhando 90% desses 210 bilhões de mensagens enviadas.
O caso é tão grave que em qualquer camelódromo onde se encontram softwares “genéricos” (desses não recomendados pela Associação das Senhoras Católicas) é possível comprar um CD com milhões de endereços eletrônicos e o software para mensagens em massa. Tudo isso pelo custo módico de R$ 5 e, provavelmente, caro leitor, o seu endereço de e-mail também está lá.
A busca por soluções à ameaça envolve algumas das mentes mais brilhantes do mundo e a “cura”, até os dias de hoje, consiste em contornar o problema, muitas vezes incomodando os usuários. Quem gosta, afinal, de ficar escrevendo aquelas letrinhas (algumas ilegíveis) do CAPTCHA?
A próxima idéia no combate ao spam é o e-mail pago, materializado na forma do CentMail que, basicamente, emitirá selos no valor de ¢ 1 (ou, US$ 0,01 se preferir). Você “colará” os selos nas suas mensagens e ela será, automaticamente, entendida como autêntica.
O pessoal dos spams, acostumado a encher o saco de bilhões de pessoas por dia, terá que pagar US$ 10.000 para mandar um milhão de mensagens.
Preocupante é a situação das listas de discussão e das pessoas que, como eu, mandam dezenas de mensagens por dia já que a intenção é tornar os “selos” um padrão para os próximos anos e a ideia é endossada por ninguém menos que o Yahoo, a empresa que se gaba de ter maior parte dos usuários de e-mail do mundo.
A grana acumulada no processo, dizem, vai para instituições de caridade. Extrapolando um pouco, isso significa que eu, sozinho, de tanto pagar para enviar mensagens, estarei sustentando um pequeno país da Europa Oriental (mais ou menos o que já me acontece pelas multas de livros atrasados na biblioteca).
P.S.:
Olha que ironia. Vim dar uma olhada em como o post tinha ficado e se os anúncios não quebraram nenhum parágrafo quando, de repente, no AdSense do Google vejo este link.
Por mais que eu adore o Linux, às vezes é preciso ter a hombridade para admitir que certas coisas em estar à margem são meio irritantes, como, por exemplo, a demora em receber atualizações (ou mesmo versões) decentes de softwares legais que todo mundo usa ou que algum dia podem ser necessários.
O Skype é um desses exemplos. Sempre fiquei P*** da vida quando precisava baixá-lo e, ano após ano, continuava lá o empoeirado RPM compilado para o Fedora Core 5 que já até virou petróleo de tão velho e ultrapassado… trata-se, na maioria das vezes, de uma questão de se conformar e continuar usando o software velho ou instalar o Win para testar o que há de novo.
O tempo passou e, finalmente, alguma alma caridosa do eBay (dona do Skype) se lembrou de nós, lançando a versão 2.1.0.47 Beta para adoçar nossas bocas.
Apesar de ainda ser bastante inferior à versão 4.1 disponível para Windows a atualização para Linux me causa certo alívio especialmente pelos binários gerados em compiladores novos (já que os RPMs para Fedora Core 5 tinham sido feitos por compiladores mais velhos que a minha avó). As melhorias no software, em si, não são nada revolucionário em comparação com a versão antiga, mas, melhorias são sempre bem-vindas.
Resta-me, agora, torcer pra que lancem atualizações para o Skype Linux em períodos de menos que 20 anos.
Gostou? Clique na figura e baixe a versão para sua distro favorita!
Recebi do Yahoo! 15 convites para distribuir aos amigos que desejarem participar do Meme, um serviço de microblogging com multimídia do Yahoo. Quem estiver interessado em receber um convite basta comentar aqui e eu enviarei.
Se você não sabe o que é o Meme do Yahoo leia esse artigo.
Começa aqui uma série chamada “softwares esdrúxulos”. Esta é uma ode a todos aqueles programadores que, como qualquer ser humano, desperdiçaram algum tempo livre para nos fornecer um software completamente inútil e sem nenhum objetivo prático. Divirtam-se!
Não haveria maneira melhor de começar esta série se não fosse pelo clássico CowSay. CowSay é um software escrito em perl que exibe uma vaquinha (em ASCII) no terminal. A “graça” é que a vaquinha repete aquilo que lhe for escrito.
Por exemplo:
Não, caro leitor, o software não faz mais nada e você ainda tem a vantagem de enviar “pipes” para a simpática vaquinha:
Ou, usando argumentos, fazer com que o carismático bovino tenha outras expressões:
Enfim, as vacas são um personagem cult no mundo hacker e se você faz o tipo divertido, com muito tempo para perder e alguma tendência a piadas de estilo duvidoso, CowSay é seu software esdrúxulo ideal. São 25 Kb instaláveis via YUM e que irão lhe proporcionar dias… horas… minutos de “diversão”.
Instale
$ su -c 'yum install cowsay'
P.S.:
Esse artigo é em homenagem ao meu amigo Igor Soares, rei das traduções e fã do cowsay.
Tudo o que o mundo precisava era mais um site à Twitter, mesmo assim ontem fui conferir o Yahoo Meme, um serviço de postagens multimídia muito semelhante ao Tumblr. Todo o desenvolvimento acontece na base do Yahoo aqui no Brasil e, por enquanto, ainda se encontra em fase alfa, mas permite que as pessoas se cadastrem como candidatos a experimentar a novidade.
A idéia é meio óbvia e, claro, alguém iria tentar isso um dia: se um blog é um montão de texto e o Twitter é um pouquinho de texto, porque não fazer um site intermediário, sem as limitações de texto do Twitter, nem tão extenso como um blog e com capacidades multimídia? O espírito é o mesmo dos microblogs: compartilhamento rápido de idéias, mas em texto, vídeo, som ou imagem e sem limite de caracteres.
O serviço **para mim** vai ser tão (in)útil quanto o Twitter; até o tenho, mas acho ridículo ficar postando essas mensagens curtas acerca do meu cotidiano pessoal ou de trabalho e, também, não acho que alguém se importe (sempre tem, claro, esse tipo de gente que lê revistas de fofoca e acha interessante a vida alheia, mas eu não tenho tempo para isso).
Empresas, por outro lado, podem usar os microblogs para mostrar o desenvolvimento de seus produtos. Adoro ver como anda o MariaDB, a NASA ou o Google e o Yahoo.
Em todo caso, como sempre, só o tempo dirá se mais essa tentativa do Yahoo dará frutos pois já ficou mais do que provado que os serviços mais idiotas podem ser um sucesso e os mais legais um fracasso.
Muitas pessoas (pelo menos assim acredito), gostariam de aprender a receita para gerar um RPM de seu software favorito; a regra de ouro se você usa uma distribuição que gerencia pacotes é “evite, sempre que possível, instalar softwares que não sejam empacotados para o seu linux”, mas, se você usa Fedora ou alguma dessas outras distros “linha dura” pode acabar ficando sem aquele programinha que você tanto gosta.
Para evitar essa tragédia, vou aproveitar o post de hoje para ensinar em passos simples como empacotar um software qualquer em RPM.
Busquei ao acaso um software qualquer que ainda não exista nos repositórios do Fedora, um exemplo bem simples é o FMIT (Free Music Instrument Tuner for Linux). O software é pequeno e pode ser instalado da maneira clássica (./configure, make, make install), por isso é perfeito para o nosso exemplo.
Primeiro passo: conseguindo o código fonte
Vá ao site do FMIT baixar o código fonte:
Com o código fonte em mãos, descompacte-o e vá dar uma olhada no que ele pede para compilar sem problemas. Se você está acostumado a instalar softwares direto pelo código fonte vai se lembrar de que o ./configure checa e avisa quais os componentes necessários para uma compilação (e instalação) correta.
Já adianto que o FMIT necessita alsa-lib-devel, freeglut-devel, fftw3-devel, jack-audio-connection-kit-devel, portaudio-devel e qt3-devel para compilar direito e também alsa-lib, fftw3, freeglut, jack-audio-connection-kit para rodar com todas as funcionalidades.
Instalar um software a partir do código fonte consiste mesmo em juntar todas as peças necessárias para poder compilar e isso exige paciência aliada a algumas habilidades detetivescas.
Segundo passo: criando o ambiente certo
Já baixamos o código fonte e ficamos familiarizados com o que nosso software vai depender para ser compilado. O próximo passo é preparar seu sistema para gerar RPMs. Instalar o ambiente de desenvolvimento é muito simples:
$ su -c 'yum install rpmdevtools'
Isso instala os softwares necessários e
$ rpmdev-setuptree
Que vai gerar as pastas e as macros usadas no desenvolvimento.
O local de desenvolvimento, você vai reparar, fica dentro de uma pasta chamada rpmbuild (~/rpmbuild). Nunca, nunca mesmo, em hipótese alguma, faça RPMs como root porque isso pode dar “permissões demais” aos seus pacotes e não queremos isso, certo?
Dentro de ~/rpmbuild há 5 pastas: SRPMS, RPMS, SPECS, BUILD, SOURCES;
- A pasta SOURCES é onde você deve jogar o código fonte do programa que vai empacotar. Não se preocupe em descompactá-lo;
- Na pasta SPECS você vai criar um script que é próprio para fazer RPMs chamado “arquivo de especificação”. Nele escreveremos todos os dados do RPM como nome, versão, descrição etc. Geralmente ele recebe o nome do programa a ser empacotado com a extensão .spec, portanto, como vamos empacotar o FMIT, ele deve se chamar fmit.spec;
- Na pasta BUILD ocorre o processo de compilação. Aqui é onde é feito o trabalho sujo pelo compilador. O seu código fonte é automaticamente descompactado aqui, checado, compilado e empacotado. Pense nessa pasta como a “linha de produção” dos seus pacotes.
- Em RPMS são jogados os pacotes prontos. Basta vir aqui e instalar as crianças. =)
- SRPMS também contém RPMs, mas não do tipo que vem com um executável. O SRPM é apenas o código fonte do seu RPM. Com um SRPM, qualquer um é capaz de reproduzir o seu RPM sem nenhum esforço. Dentro dele temos o código fonte do software, o seu arquivo .spec ou qualquer outra coisa que você tenha colocado em seu pacote.
Terceiro passo: Criando o seu arquivo .spec
A parte mais chata é essa. Um arquivo .spec tem partes muito bem definidas que precisam ser levadas à risca para gerar um bom pacote, mas não se assuste, hoje em dia há muita coisa já pronta ou automatizada para nos ajudar. Por exemplo, você pode usar o VI/VIM para gerar um arquivo .spec genérico e “oco” para você:
Entre na pasta dos arquivos .spec
$ cd ~/rpmbuild/SPECS
Mande o VI/VIM criar o arquivo .spec vazio:
$ vim fmit.spec
Reparou que “automagicamente” o nosso arquivo de especificação já veio com os campos a preencher? Alguns campos são óbvios (outros nem tanto). Senão, vejamos:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | Name: # O nome do programa Version: # A versão do programa Release: 1%{?dist} # A release do pacote. Aqui vem aquela parte -1.fc11, -2.fc11... Summary: # Curta descrição do software Group: # A qual grupo pertence o software? Por exemplo: Applications/Multimedia License: # Qual a licensa vigente sobre o software? Por exemplo, GPL, MIT... URL: # Site do desenvolvimento upstream Source0: # O link do código fonte. BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) # Troque esta parte por %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: # Todos os pacotes necessários para a compilação. Requires: # Todos os pacotes que são “dependências” para o seu software rodar bem. %description # Uma descrição mais completa do seu software %prep # Nesta seção o seu código fonte é “tratado”. Descompacta-se, aplica-se patches... %setup -q %build # Aqui vem, automática a parte do ./configure e do make %configure make %{?_smp_mflags} %install # Instalação do software rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT %clean # Limpeza do seu “espaço de trabalho” para garantir que esteja limpo se precisar usar de novo. rm -rf $RPM_BUILD_ROOT %files # Diga nesta seção quais os arquivos presentes no seu RPM, assim, ao desinstalá-lo, não sobrará nenhum “lixo”. %defattr(-,root,root,-) %doc %changelog # Para manter um histórico do seu trabalho |
Quarto passo: preencendo seu arquivo .spec
Vamos preencher o nosso spec passo a passo. A primeira seção é bem simples, são apenas informações gerais:
1 2 3 4 5 6 7 8 9 10 | Name: fmit Version: 0.97.7 Release: 1%{?dist} Summary: Free Music Instrument Tuner for Linux Group: Applications/Multimedia License: GPLv2 URL: http://home.gna.org/fmit/index.html Source0: http://download.gna.org/fmit/fmit-0.97.7.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) |
Na segunda seção, colocamos as dependências para compilar e para funcionar:
BuildRequires: alsa-lib-devel >= 0.9 BuildRequires: freeglut-devel BuildRequires: fftw3-devel BuildRequires: jack-audio-connection-kit-devel >= 0.103 BuildRequires: portaudio-devel BuildRequires: qt3-devel Requires: alsa-lib >= 0.9 Requires: fftw3 Requires: freeglut Requires: jack-audio-connection-kit >= 0.103
Na terceira seção, uma explicação mais detalhada sobre o software:
1 2 | %description Free Music Instrument Tuner for Linux, bla, bla bla... |
Agora, na quarta seção, um detalhe importante: o FMIT é um software muito simples que pode ser compilado com ./configure, make e make install sem precisar de mais nenhum parâmetro adicional, por isso, não precisa mexer em nada nessas partes aqui:
1 2 3 4 5 6 7 8 9 10 11 12 13 | %prep %setup -q %build %configure make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT %clean rm -rf $RPM_BUILD_ROOT |
É claro que se nosso compilador precisasse de alguma instrução extra haveria mais coisas a fazer na quarta seção, mas isso não vem ao caso agora; quem sabe num próximo artigo?
A quinta seção vai catalogar tudo que há no seu RPM para instalação/desinstalação:
1 2 | %files %defattr(-,root,root,-) |
1 | %doc AUTHORS COPYING ChangeLog TODO |
Liste tudo que pode ser considerado documentação no seu pacote
Você se lembra dessa parte? “%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} –n)” Isso gerou, do lado da pasta BUILD uma nova pasta chamada BUILDROOT. Essa novas pasta é uma pasta “fake” onde o software vai se instalar pensando que está sendo instalado no sistema. Ela tem capacidade de imitar todas as pastas da pasta / de modo a garantir que o software consiga encontrar os lugares devidos à sua “acomodação”. Você deve olhar nessa pasta para descobrir quais arquivos precisam ser “declarados”
1 2 3 4 | %{_bindir}/fmit # %{_bindir} significa /usr/bin %{_datadir}/fmit # %{_datadir} significa /usr/share %{_datadir}/applications/fmit.desktop %{_libdir}/*.a # %{_libdir} significa /usr/lib |
Na sexta seção, mantenha um histórico do seu trabalho:
1 2 3 | %changelog * Sun May 10 2009 Henrique "LonelySpooky" Junior - 0.97.7-1 - Initial package |
Quinto passo: gerando o RPM
A etapa mais fácil. Mande o rpmbuild gerar seu rpm:
$ rpmbuild -ba ~/rpmbuil/SPECS/fmit.spec
Se tudo correr bem você vai ver as mensagens de compilação e, ao fim, as seguintes linhas:
Gravou: /home/lonely/rpmbuild/SRPMS/fmit-0.97.7-1.fc11.src.rpm
Gravou: /home/lonely/rpmbuild/RPMS/i586/fmit-0.97.7-1.fc11.i586.rpm
Gravou: /home/lonely/rpmbuild/RPMS/i586/fmit-debuginfo-0.97.7-1.fc11.i586.rpm
Como prometido, na pasta RPMS estará seu rpm do fmit e um pacotinho com informações de debug que você não precisa.
Este é um exemplo tão genérico quanto possível e tentei apresentar de forma simples como proceder, mas, convém avisar, gerar RPMs varia muito dependendo da linguagem de programação e mesmo um pacote simples como esse pode ser feito de forma mais “elegante”. Em todo caso, espero que tenha matado a curiosidade de alguns ou dado um “empurrãozinho” em quem deseja começar no empacotamento.
Leituras recomendadas
- Maximum RPM
- Guia de empacotamendo do Fedora — (en)
- Nomenclatura de pacotes do Fedora — (en)
- How-To de criação de pacotes — (en)
- Guia RPM — (en)
Loading ...
Comentários