Zhockon 0.1.1 lançado

É com o maior prazer que anuncio aqui a conclusão do Zhockon 0.1.1. Esta é uma edição que segue a série 0.1.x, válida até abril de 2010. Esta nova versão da plataforma conta com uma série de novidades que vieram para facilitar a vida do usuário e do testador. Não foram feitas modificações no motor Euphoria, muito menos no Entropia. Dentre as melhorias, pode-se destacar os seguintes aspectos como os mais interessantes:

• Criação do Zhockon Builder (build.py)
• Conteúdo do ZOUtils movido para o Aurora
• Conteúdo do ZHImage movido para o Corona
• Acréscimo de uma imagem nas propagandas (zhockon_skeleton.png)
• Incluído atalho para teste do cubo (cube.py)
• Incluído Invasores para Zhockon (invaders.py)
• Criação de uma estrutura de caminhos (engine.py)

Ainda assim, há muitas coisas a melhorar, como uma melhor estrutura de caminhos (a atual versão está com uma implementação muito bagunçada), provalvemente numa construção de árvore. Somente para constar, apesar de que surgiram os diretórios corona e aurora nesta versão, estes não serão desenvolvidos no momento, pois tanto um quanto o outro possuem as datas de quando iniciar bem definidas (na série 0.2.x e 0.3.x, respectivamente).

Dentro de alguns dias estarão disponíveis as versões “de fábrica”: i386, x86_64 e win32. Para quem já deseja testar o zhockon 0.1.1, ele estará disponível em algumas horas em “Download de pacotes da plataforma”, na página oficial da Plataforma Zhockon de Desenvolvimento de Games. Ele já encontra-se disponível no canal SVN.

O Novo Open Source & Cia.

Muitas coisas ocorreram nos últimos meses, e o blog Open Source & Cia. merecia uma bela de uma repaginada. Neste post me dedicarei a falar o que mudou, o que permaneceu e a situação atual do site. Com o advento da plataforma Zhockon de games e a propaganda por meio de grandes portais como o BR-Linux e o Viva o Linux, o OS & Cia. passou a ser um ponto de muitas visitas pelos mais diversos leitores dos mais variados gostos.

Em apenas algumas semanas de publicidade do projeto levou o blog a triplicar sua média de visitas diárias e passar de 3500 visitas no total desde a inauguração deste pequeno portal. Com isso, nada mais justo por um contador de visitas na barra lateral em conjunto de mais informações do Zhockon, como a apresentação dos tweets do projeto na página principal. O RSS saiu do topo da página e fui obrigado a por links em algum lugar. Acredito que agora esteja mais intuitivo do que antes com estas novas ferramentas. Como também podem perceber pela imagem que coloquei aqui, o site está de cara nova. O motivo mais claro para eu estar trocando de tema no WordPress é a possibilidade de por o slogan do Open Source & Cia. no topo da página: Liberdade, Coca-Cola Zero e muito Rock’n'Roll. Como já tinha falado na última vez que troquei a aparência do blog, eu não sou de mudar toda hora isso. Porém agora é o momento certo de mudar, e para melhor.

Outra coisa a se considerar é de que eu já estava vendo muito blog com o mesmo tema que o meu. Sempre tento variar, só quem é usuário do WordPress.com sabe o problema de personalização que tenho aqui. Tudo é muito estático. Apesar disso, sempre tento mudar bastante para continuar bonito e claro, diferente dos outros. Para não parecer de que dependo do Zhockon para que o site continue sendo bem visitado, estarei inaugurando no próximo post uma nova categoria de textos para o mesmo: Cinema. Pelo nome já dá para se pensar do que tratarei nestas postagens. Este é meu compromisso enquanto mantenedor do OS & Cia.: tornar o mais acessível para todas as pessoas meu site, diversificando cada vez mais os assuntos tratados aqui. Isso aproxima o blog cada vez mais à convergência.

O que já estava muito bom será melhor agora no Open Source & Cia. Com a chegada do fim de ano, as clássicas páginas Espaço CKZ, Firefox e OS Unltd receberão atenção extra. Tudo para manter a qualidade de três ótimas seções do site, que andam um tanto paradas ultimamente. Como podem ver, minha atenção não está totalmente em cima da Plataforma Zhockon, mas também de partes essenciais deste agora pequeno portal. Os vídeos poderão voltar com toda a força nas postagens. No momento, só há o “Desvendando o Arch Linux” que possui um vídeo. Estou pesquisando formas de implementar o vídeo aberto aqui no blog. Logo aparecerá, e tu, caro leitor, não irá perder um sequer detalhe destas novidades.

Claro que não deixaria de falar sobre meu projeto principal aqui nas novidades do Open Source & Cia. O desenvolvimento dos motores de jogos por enquanto está parado, o foco para a versão 0.1.1 é a estabilidade e compatibilidade com boa parte dos sistemas. Na versão 0.1.2 já poderá ser visto melhorias no Euphoria. A primeira será lançada em alguns dias, e a segunda está marcada para 12 de dezembro. Falando em números, a situação atual do site é a seguinte: 10 páginas, 8 categorias e 137 tags até a hora da publicação deste mesmo. Espero ter agradado nesta sextagésima quarta postagem.

Zhockon: Uma Nova Esperança

Segue abaixo uma adaptação do artigo “Zhockon – Surge uma nova esperança no campo de games”, de minha autoria, publicado no portal Viva O Linux. Nada mais justo reproduzi-la no blog onde é hospedado a página oficial da Plataforma Zhockon de Games. Acredito que muitos já devem de ter reclamado aos montes que um jogo X não funciona nativamente no sistema operacional que tu usa. Apesar deste grande problema que temos nos unixes (GNU/Linux, BSDs, OpenSolaris…), existem até algumas soluções, nem tanto eficientes, mas que “quebram o galho”. Uma delas, acredito que a mais conhecida, é o WINE, utilizado por mim e creio que por muitos outros, muito mais para rodar jogos exclusivos para a plataforma Windows do que programas deles. Afinal, o problema frequente que temos nestes sistemas é a carência de bons títulos (não que não tenha, Quake 4, Yo Frankie! e America’s Army são exemplos), e não de bons programas, que aliás temos aos montes e ótimos. A maioria já sabe que o WINE, apesar de ter evoluído muito nos últimos anos (lembro que quando eu comecei a usar o Linux ele não servia de nada para mim), ainda não é uma solução definitiva para os games começarem a ser uma realidade multi-plataforma. Quero dizer aqui que não desmereço o trabalho de alguém em cima do WINE, muito pelo contrário, elogio, pois já conseguiram fazer coisas fantásticas com esta API ocorrer. Bem, mesmo se não tivesse esta boa ferramenta, não voltaria para as “Janelas”. Já existe uma boa gama de jogos nativos para UNIX, como os que já citei e outros, e mais alguns, só que não com a enorme diversidade que temos no Windows. Frets On Fire, Battle For Wesnoth e Super Tux Kart são bons jogos que, apesar de não terem gráficos impressionantes como o Quake 4 ou o Yo Frankie!, são games bem trabalhados, tanto no desenho quanto na sua jogabilidade. O que tem mudado bastante neste campo é o surgimento de ótimos projetos na categoria, seja ele um motor, um framework, um game ou até mesmo um simples aplicativo utilitário. Falta é uma melhor integração entre eles.

E é por causa destes problemas que comecei este projeto na área de jogos. O Zhockon, como é chamado, é uma plataforma integrada de desenvolvimento de games. Sua estrutura está toda elaborada com o uso de bibliotecas de três tecnologias multi-plataformas: OpenGL, OpenAL e SDL. Alguns perguntariam se somente o SDL não seria o suficiente, e a estes responderia que não, pois ele depende do OpenGL para o desenho de gráficos 3D e do OpenAL para o áudio 3D, sendo que o resto – que não é pouco – rede, lógica do jogo, personagens e objetos (sprites) e muitos outros ficaria a cargo da própria biblioteca. O objetivo aqui é mesmo criar uma boa alternativa ao DirectX.  Já existem construções de duas engines para o desenvolvimento de games (Entropia e Euphoria, desenvolvidas, respectivamente, em C++ e Python) que estão sendo ligadas com as três tecnologias que citei. Elas se encontram em variados estágios de desenvolvimento, pois o Entropia é um projeto externo à plataforma, enquanto o Euphoria está sendo desenvolvido internamente. É esperado que até o fim da série 0.1.x a integração da primeira à plataforma e a construção da segunda estejam terminadas. Com isso, a plataforma já estará apta para o desenvolvimento primário de games. Vale lembrar que ela não estará concluída, e mais características serão adicionadas no futuro. Dentre estas, já estão previstos o desenvolvimento de três motores: Corona, Plenora e Aurora. O primeiro será um conjunto de scripts que se integrarão com os mais diversos aplicativos ligados à programação de games, como o Blender, o Inkscape, o Eclipse, entre muitos outros. O segundo será uma estrutura para suportar extensões para a plataforma, para que se possam utilizar as mais diferentes game engines e tecnologias que desejar. E o terceiro será uma grande interface gráfica que trará um centro de controle para o Zhockon e um aplicativo nos moldes do Steam, distribuindo e instalando da maneira mais fácil possível qualquer jogo que seja da plataforma. Pode até parecer que é muita coisa para um projeto só, mas como afirmei anteriormente, esta ideia surgiu para integrar os mais diversos projetos na área de jogos, o que acarretará um menor custo para o desenvolvimento da plataforma. Ideias como o DJL, o instalador Ubuntu Games e até mesmo o Entropia Engine ++ são exemplos claros disso. E continuarei a ter esta boa prática. Graças a estes projetos externos, minhas ideias e a colaboração de algumas pessoas ou até muitas, tenho certeza de que o Zhockon poderá se tornar uma feliz realidade.

Under a Blood Red Sky

Hoje irei falar de uma banda bastante conhecida pelo mundo inteiro, como já havia feito no post anterior sobre rock. O conjunto da vez é irlandês, da cidade de Dublin. Conhecido (e muito) como U2 ele é composto por Bono Vox como vocalista, The Edge na guitarra, Adam Clayton no baixo e Larry Mullen na bateria. A banda possui um estilo musical contagiante, especialmente em nos primeiros álbuns, concentrados nos anos 80, como, por exemplo Boy e War, que contém músicas como The Electric Co., Sunday Bloody Sunday e New Year’s Day onde é mostrado o mais puro rock que já havia visto. Também vale destacar álbuns como The Joshua Tree e Achtung Baby (este último já no início de 90), onde temos faixas muito conhecidas como Where The Streets Have No Name, With Or Without You e Bullet The Blue Sky no primeiro e One e Mysterious Ways no segundo. Em suas músicas mais calmas vemos tendências cristãs, já que boa parte dos membros são católicos. Acredito que, mesmo quem não seja desta religião, gostem destas mesmas, por serem envolventes. Em outras músicas, vejo uma aproximação ao pop, que não chega a ser um problema tão grande quando falamos desta banda. Há também outros álbuns ainda na década de 80, como October, The Unforgettable Fire com músicas como Pride (In The Name of Love), e o álbum Rattle and Hum com faixas como Desire e I still haven’t found what I’m looking for. Quanto ao segundo álbum da banda, October, lançado em 1981, eu conheço muito pouco sobre ele para falar algo. Não tenho muito conhecimento sobre os álbuns feitos durante a década de 90 por eles (com exceção do Achtung Baby), por isso não irei comentar muito sobre estes. Foram o Zooropa e o Pop, e pelo que pesquisei o primeiro segue o sucesso de Achtung Baby e o segundo é uma pequena coletânea de originais feitos por eles. Vejo que muitos criticam estes mesmos por uma certa perda de personalidade nos mesmos. Pelo que já escutei de algumas músicas destes álbuns, e eles parecem exagerar no eletrônico e no pop e esquecem das raízes que tinham no rock. Bem, pelo jeito estes não devem de sido tão bons quanto outros que citei anteriormente nesta postagem.

(Da direita para esquerda, Adam Clayton, Bono Vox, The Edge e Larry Mullen. É uma foto bastante recente, em No Line on the Horizon)

Em contraposição aos dois últimos álbuns da década de 90, vemos um renascimento do bom e velho estilo do U2, com músicas profundas e outras agitadas com o mais puro rock. Começamos com All That You Can’t Leave Behind, que possui ótimas faixas como Elevation, Walk On e Beautiful Day. Creio que eles começaram a resgatar o que tinham de melhor na banda e não era mostrado desde Achtung Baby. Logo depois vemos o lançamento de um dos maiores sucessos da banda desde o Joshua Tree, álbum já consagrado de U2, o How To Dismantle An Atomic Bomb, que contém várias excelentes músicas, como a Vertigo, City of Blinding Lights, All Because of You, Original of Species, Love and Peace or Else e Sometimes You Can’t Make It on Your Own. Aliás, foi o álbum com que eu comecei a conhecer esta fantástica banda. Não tenho este álbum só porque tenho um show em DVD da Vertigo World Tour em Chicago que tem todas estas músicas e mais. Já devem ter notado que gosto bastante do U2. Realmente, depois do Nirvana, é a banda que eu mais escuto no meu dia-a-dia. O último álbum foi lançado recentemente, o No Line on The Horizon, que possui também boas músicas como a faixa homônima, Get On Your Boots, Magnificent e I’ll Go Crazy If I Don’t Go Crazy Tonight. Nestes três últimos álbuns podemos ver uma excelente produção em todos os sentidos, no baixo, na guitarra, na bateria e no vocal. Até por isso que existem muitas músicas bem compostas nestes mesmos. Há coletâneas feitas pelo U2 muito boas como The Best Of 1980-1990, The Best Of 1990-2000 e U218 Singles, sendo que este último eu tenho e recomendo a quem goste banda para comprar e, claro, escutar. Para finalizar, temos também álbuns ao vivo, como Wide Awake in America – não conheço as faixas dele – e Under a Blood Red Sky (agora deu para ver onde tirei minha inspiração para título, não?), onde a banda toca sucessos como I Will Follow, Sunday Bloody Sunday, The Electric Co. e New Year’s Day. Acho que não me esqueci de citar nada sobre esta grande banda. Ela aliás anda inovando um bocado neste último álbum e tour (U2 360° Tour), exibindo por exemplo um de seus shows pelo YouTube. Especulou-se de que o No Line On The Horizon iria ser distribuido gratuitamente pela internet, porém não ocorreu. Apesar disso, acredito que vá ser uma tendência no cenário da indústria fonográfica em virtude da pirataria. Os ganhos das bandas já estão sendo maiores em shows do que em cópias vendidas de álbum. Ainda mais no caso do U2, onde cada show é único e muito bem planejado e estruturado, é só ver o show disponibilizado na internet que tu verás isso sendo confirmado. Enfim, na minha consciente opinião, o U2 tem ainda uma boa estrada a caminhar e continua sendo uma ótima banda e que suas músicas atuais nada deixam a desejar às do passado.

Configurando o Arch Linux (2ª parte)

Como já havia comentado na primeira postagem sobre esta configuração, ela não é tão complicada quanto a de outras distros GNU/Linux no modo texto. Claro que deve de haver alguma outra distribuição que seja muito mais simples e fácil de “arrumar a casa”, porém a que eu melhor conheço é esta e aqui mostrarei o final desta dica.

INTERNACIONALIZAÇÃO DO SISTEMA

Há muita pouca coisa a se fazer nesta parte. Um pedaço dela já foi feito no último post (quando o valor de LOCALE no rc.conf foi trocado para pt_BR.utf8 ou pt_PT.utf8) e outra será feita agora. Num editor de textos qualquer, acesse como root o arquivo /etc/locale.gen. Então descomente essas linhas:

pt_BR.UTF-8 UTF-8
pt_BR ISO-8859-1

Ou, caso tu sejas um português, descomente as linhas que estão abaixo destas que citei:

pt_PT.UTF-8 UTF-8
pt_PT ISO-8859-1

Isso fará com que todos os programas utilizados na distribuição que possuem suporte para a língua portuguesa usem-na. Caso o programa não tenha esta tradução, ele automaticamente usa o inglês. Simples e fácil, não?

ALTERANDO PERMISSÕES DA REDE

Para este processo utilizamos os arquivos /etc/hosts.deny e /etc/hosts.allow. O primeiro proíbe o acesso à rede de tua máquina por quem tu definires nele. O segundo faz o contrário, permite o mesmo acesso. A sintaxe dos dois é muito parecida. Segue abaixo um trecho de código deste dos respectivos:

ALL: ALL: DENY
ALL: ALL: ALLOW

O primeiro “ALL” serve para dizer qual aplicação será permitida e/ou proibida de acessar a rede de tua máquina. Note que os programas que tu vais especificar aqui são de acesso remoto, e esta configuração nada tem a ver com o acesso a internet. Se tu não precisares disso, siga adiante. O segundo “ALL” serve para especificar qual usuário poderá ter a permissão e/ou a proibição. Como neste exemplo:

ssh: usuario: ALLOW

Eu sou um usuário do Arch Linux há um tempo e digo que faço uma má prática nesta parte: eu comento o ALL: ALL: DENY e descomento o ALL: ALL: ALLOW. Recomendo fortemente que tu não faças isso, pois pode comprometer um pouco da segurança de teu sistema. É o clássico “Faça o que eu digo, não faça o que eu faço”.

TROCANDO O NOME DA MÁQUINA

Caso a troca do valor de HOSTNAME no rc.conf não tenha dado certo no último post, tente trocar o nome que se encontra em /etc/hosts, na coluna onde diz hostname. Com estes campos trocados eu tenho certeza de que ele irá trocar o nome da máquina. Além de enfeitar teu terminal, o hostname é um jeito mais amigável de chamar uma máquina. Se não fosse por isso, você teria que decorar o endereço IP de cada máquina tua. Seria bem desagradável, não?

OUTROS ARQUIVOS DE CONFIGURAÇÃO

Temos também o clássico /etc/fstab, o /etc/mkinitcpio.conf, o /etc/modprobe.d/modprobe.conf e o /etc/resolv.conf. Reuni estes porque provavelmente tu não vais modificar ele, desde que use o HAL previamente configurado e não necessite customizar o kernel. O fstab lista pontos de montagem. Para quem vive no terminal, ele até é um tanto útil para dispositivos removíveis(pendrive, cartão, CD, DVD…), mas para quem usa o modo gráfico como eu, com o hal e seus apetrechos ativados, não é necessário modificar alguma coisa aqui. O resolv.conf é um arquivo que dá preferência ao endereço IP que a máquina quer utilizar. Nunca precisei mexer neste, apesar de que ele poderia ajudar-me a parar as constantes mudanças de endereço. O modprobe.conf tu só vais mexer caso algum módulo não esteja sendo carregado corretamente. Esse eu precisei mexer uma vez, para que o microfone de meu notebook funcionasse:

options snd-hda-intel model=auto

Já vou deixando aqui caso alguém esteja com o mesmo problema. O mkinitcpio.conf é onde podemos customizar a inicialização do kernel Linux, que módulos deve utilizar e alguns serviços. Eu tive de mexer aqui para que o FBSplash pudesse funcionar na inicialização. Quanto à instalação deste aí que citei, não recomendo muito, pois tu tens de fazer muita coisa para que ele fique tinindo. Quem sabe, algum dia eu publico um post sobre esse mesmo assunto de que tratei.

MANTENDO O SISTEMA COM O PACMAN

O pacman é o gerenciador de pacotes do Arch Linux, assim como o apt-get é para o Debian/Ubuntu, o yum é para o Fedora, e por aí vai. É programa extremamente simples de usar. Antes de utilizá-lo, devemos ver se está apropriadamente configurado. Acesse o arquivo /etc/pacman.conf e veja se tem um pedaço do código parecido com este:

[core]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/mirrorlist

[extra]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/mirrorlis

[community]
# Add your preferred servers here, they will be used first
Include = /etc/pacman.d/mirrorlist

Se estiver um pouco diferente, não se assuste, provavelmente nas linhas onde tem o Include deve de haver um endereço web. Recomendo que troque para o /etc/pacman.d/mirrorlist. Só resta ver qual mirror deseja ativar no mirrorlist. Para tanto, descomente uma ou mais linhas de servidores, como no trecho do arquivo abaixo:

# Brazil

#Server = ftp://archlinux.c3sl.ufpr.br/archlinux/$repo/os/i686
#Server = http://archlinux.c3sl.ufpr.br/$repo/os/i686
#Server = ftp://ftp.las.ic.unicamp.br/pub/archlinux/$repo/os/i686
Server = http://pet.inf.ufsc.br/mirrors/archlinux/$repo/os/i686

Com isso configurado, tu estás pronto para usar o pacman. Para sempre manter os aplicativos e bibliotecas do sistema atualizados, sempre digite, como root num terminal o seguinte:

# pacman -Syu

Somente com este comando, tu consegues atualizar os repositórios na tua máquina e atualizar todos o pacotes. Caso queira instalar e/ou atualizar um programa (note que o comando que apresentei já atualiza todos eles), segue o exemplo abaixo, novamente como root no terminal:

# pacman -S firefox

Caso tu não queiras mais o programa instalado na tua máquina, execute o seguinte comando, do mesmo modo que os outros dois:

# pacman -Rscn firefox

Este comando não só remove o programa, mas também todos as bibliotecas que ficarão inutilizadas depois da remoção do mesmo e outros pacotes relacionados com ele. Eu usava a opção -Rd, porém ela deixa muito lixo no teu sistema e por isso recomendo a que está no exemplo. Então, a manutenção é fácil, não? Pois bem, este é o objetivo do Arch.

A única parte da configuração que ficou pendente foi a da inicialização no GRUB ou no LILO, que não são exclusivas da distribuição e, portanto, pode-se utilizar as mesmas modificações que tu fazes em outras distribuições. Por aqui encerro esta dica, na esperança de que a informação que passei aqui tenha sido pelo menos um pouco útil e, claro, correta e precisa. A todos agradeço a atenção pela leitura de mais uma postagem minha.

Zhockon Disponível em Alpha

Eis aqui o grande anúncio de meu projeto, como havia prometido a um tempo atrás. O projeto trata-se de uma plataforma de games escrita nas linguagens de programação Python, C e C++, muito utilizadas em games da atualidade. Meu trabalho na base da plataforma é um tanto facilitado com a ajuda de bibliotecas de três distintas tecnologias, SDL, OpenGL e OpenAL, por meio de dois motores padrões: o Entropia (de autoria de terceiro), escrito em C++, e o Euphoria (de minha autoria), escrito em Python. Ainda há a ajuda de bibliotecas multimídia (inicialmente apenas de manipulação de imagens) e de scripts, que formará durante o desenvolvimento o Corona, escrito em Python. O foco de desenvolvimento na primeira série Alpha da plataforma (0.1.x) será o Euphoria e o Entropia, bem como a busca pela portabilidade de todo o software, ou seja, até  o 0.1.9 o Zhockon conseguirá a capacidade de rodar dentro de um pendrive. O resto do roteiro para o estágio alpha eu irei descrever na página do projeto, que a partir de já sofrerá modificações. Como plano de anúncio, resolvi fazer várias coisas para o lançamento:  a primeira será a distribuição da marca da plataforma, que estará em diversos pontos do blog e da página do projeto, bem como em outros lugares. Todo o material de divulgação estará disponível junto com o software. Pensarei ainda se farei um pacote separado deste. A segunda é o anúncio em 9 fóruns escolhidos por minha pessoa, acredito que com poucos critérios, como já comentei no post anterior. A terceira será a atenção maior que darei ao projeto aqui no Open Source & cia., deixando um pouquinho de lado as dicas, artigos e experiências e relatando mais sobre a evolução da plataforma. Calma, não deixarei o blog pobre de recursos, só não haverão posts na mesma frequência em que eu estava publicando. No momento que estou escrevendo, a versão do Zhockon é a 0.1.0, já disponível no sourceforge para download e/ou desenvolvimento. Confesso que sua primeira versão não é nada fácil de configurar, porém melhorarei assim que novas versões surgirem. Uma vantagem em questão é que estão disponíveis os códigos de praticamente todos os projetos relacionados à plataforma. Outra é a disponibilidade de builds em amd64 e i386 (um build para win32 já está sendo preparado e será lançado em breve). Para mais informações, acesse a página principal do projeto aqui no blog.

Preparativos

É a semana da divulgação de meu projeto, que mantenho em meio segredo, já que contei para um bocado de pessoas e dei pistas aqui no blog sobre do que ele se trata. Apesar de algumas revelações, o que não foi descoberto será mantido até a data anunciada na página Top Secret, que pegará o nome verdadeiro do projeto. Pensei muitas vezes em ter uma página própria para tal, porém creio que um setor de meu blog será o suficiente, desde que ele seja bem aproveitado. Uma boa parte da semana foi gasta em cima da finalização de alguns trechos de códigos, alguns documentos e materiais de divulgação. Tenho certeza de que tudo isso não será em vão, pois o que estou preparando e no momento desenvolvendo é uma boa idéia, e como outras poderá progredir mais ainda se houver contribuintes ao longo do desenvolvimento do projeto. Entrarei em mais detalhes no post de lançamento, e em lugares que selecionei para publicar seus objetivos. Os lugares, em suma maioria, são fóruns brasileiros de distribuições GNU/Linux, pois acredito que, pelo que este software pode oferecer num futuro próximo são os usuários deste sistema que poderão, quem sabe, aproveitar as vantagens do mesmo. Quanto ao serem brasileiros, bem, eu tenho a capacidade de escrever em inglês, porém meu vocabulário é muito pobre e me preocupo quanto ao transmitir por um texto minhas idéias exatamente como as penso. Mais por isso que escolhi na maioria fóruns de discussão que falam na língua portuguesa. Não é uma questão de seleção, apenas de limitações quanto à minha pessoa. Comentarei nos textos dos fóruns que, caso alguém possa, que traduza o texto para outras línguas, ou até mesmo corrija meu texto em inglês (será posto em poucos fóruns, em virtude de meu pobre inglês). Agradecerei muito a quem puder já contribuir nesta parte. Esta é a última postagem antes do anúncio, que ocorrerá no dia 12 de outubro, segunda-feira. As ferramentas que serão utilizadas para o desenvolvimento já estão começando a aquecer, para poderem ser utilizadas desde o momento do anúncio. Acho que não haverá atrasos, pois tudo está sendo feito antecipadamente. Para finalizar este post, largo mais uma característica do projeto: seu sistema de versões funcionará da seguinte forma: o release marcado para 12 de outubro será o 0.1.x, e permanecerá durante um semestre com as suas metas a serem alcançadas, até o dia 12 de abril, onde sairá o release 0.2.x, com o mesmo esquema, até 12 de outubro de 2010, e por aí vai, consecutivamente. Releases de 0.1.x a 0.4.x serão considerados versões alpha, enquanto de 0.5.x a 0.8.x serão versões beta. Todos os releases de 0.9.x serão RC (Release Candidate) e o 1.x.x, claro, a versão final. Espero ter sido esclarecedor nesta parte. Se não fui, pelo menos espero ter agradado com as notícias que coloquei nesta postagem.

Configurando o Arch Linux (1ª parte)

Depois de muitíssimo tempo sem postar dicas, resolvi tomar vergonha na cara e escrever uma. Acho que não irei me delongar tanto a ponto de escrever mais de duas ou três postagens, pois o que escreverei aqui não é tão complexo e longo. O Arch Linux, como já citei em outro post, é uma distribuição simples de configurar. Só não gosta quem tem pavor do KISS (não é a banda, é o Keep It Simple, Stupid). Bem, eu não tenho, e acho que tu, caro leitor, também não tens. Aqui me atentarei mais às configurações realizadas para uma inicialização de sistema tranquila.

CONFIGURANDO A LOCALIZAÇÃO

O que mais irei alterar nesta postagem será o /etc/rc.conf. Portanto, prepara teu vi, emacs, kwrite, gedit ou qualquer outro editor de textos e um acesso ao administrador (pode ser sudo ou usuário direto), pois  aqui vão uma enxurrada dicas do que se por nas linhas do principal arquivo de configuração do Arch Linux:

• LOCALE: Esta é a variável que cuida do idioma do sistema. A língua escolhida neste ponto será usada por todos os programas que suportem-na. Vale lembrar que tu podes obter uma lista dos idiomas disponíveis executando locale -a em um terminal. O padrão (en_US.utf8) deixará o sistema em inglês. Para deixá-lo em português deve-se utilizar pt_BR.utf8 ou pt_PT.utf8, para o português brasileiro ou europeu.
• HARDWARECLOCK: Especifica se o relógio físico da máquina, o qual é sincronizado durante a inicialização, está configurado de acordo com dois tipos de horários: a hora universal (UTC) ou local (localtime). O UTC é de grande utilidade para locais que possuem o horário de verão, enquanto o localtime torna-se necessário se tu utilizas no mesmo computador um sistema operacional que não diferencia o horário um do outro.
• TIMEZONE: Especifica o fuso horário da tua localidade. Os valores prováveis aqui são os caminhos relativos a um arquivo, começando do diretório /usr/share/zoneinfo. Por exemplo, se você mora na região leste do Brasil, deve utilizar Brazil/East, que se refere ao arquivo /usr/share/zoneinfo/Brazil/East. Outras opções são Brazil/West, Brazil/Acre e Brazil/DeNoronha. Os portugueses devem usar apenas Portugal.
• KEYMAP: O mapa de teclado a ser utilizado. Se tu tens um teclado brasileiro (com a tecla ç), deves utilizar br-abnt2. Se possui um teclado americano e quer utilizar acentos, deve usar us-acentos. Em /usr/share/kbd/keymaps encontrará outras opções. Essa configuração somente afetará o console do sistema e portanto não terá efeito algum nos gerenciadores de janelas ou no X puro.
• CONSOLEFONT: Define a fonte utilizada no console. Possíveis valores encontram-se em /usr/share/kbd/consolefonts. Confesso que essa eu comecei a utilizar poucas semanas atrás, e sabe que gostei? Arranjei uma boa fonte (uma tal de Terminus Font que tanto falavam bem) e estou utilizando até este exato momento.
• CONSOLEMAP: Define o mapa de console utilizado. Os mapas possíveis estão em /usr/share/kbd/consoletrans. Você irá querer configurar isso para um mapa relacionado ao seu locale (8859-1 para Latin1, por exemplo) se estiver usando um locale utf8 acima, e utilizar programas que geram saída 8-bit. Se somente utiliza o X11 no dia-a-dia não precisa se preocupar pois essa configuração só afeta a saída de programas no console.
• USECOLOR: Ativa (ou desativa) mensagens de estado coloridas durante a inicialização do sistema. Eu pessoalmente gosto daquele boot colorido que temos no Arch Linux. Bem, todas as máquinas aqui, exceto a que estou utilizando agora para escrever esta dica (ela usa o fbsplash na inicialização – e que sofrimento para instalar isso!) tem configuradas por padrão o boot em modo texto e, claro colorido.

CONTROLANDO MÓDULOS OPCIONAIS

Ainda no mesmo arquivo há um setor que cuida somente de carregar os módulos do kernel (parecidos com os drivers do Windows) que não foram inicializados automaticamente. Quase sempre temos poucos deles a serem carregados neste arquivo, pelo menos nos casos aqui em que instalei esta distribuição GNU/Linux. Então vamos lá:

• MOD_AUTOLOAD: Se configurado para “yes”, o Arch irá detectar seu hardware durante a inicialização e tentar carregar os respectivos módulos. Isso é feito com a ferramenta hwdetect. Nunca testei para ver o que deve de acontecer se deixo em “no” nesta variável. Acho que nem é bom saber…
• MOD_BLACKLIST: Essa é uma lista de módulos que você não quer que sejam carregados durante a inicialização. Por exemplo, se não gostar daquele irritante alto-falante interno, pode colocar o módulo pcspkr nessa lista negra. É bom avisar aqui que esta linha está marcada como deprecated, pois não é recomendada seu uso.
• MODULES: Aqui você pode listar os nomes dos módulos a serem carregados durante a inicialização sem precisar relacioná-los aos dispositivos, igualmente ao modprobe.conf. Somente adicione o nome do módulo aqui, e coloque quaisquer opções adicionais no modprobe.conf se necessário. Adicionando-se um ponto de exclamação (!) antes do módulo irá impedir seu carregamento na inicialização (não é o mesmo que o MOD_BLACKLIST!), possibilitando “comentar” certos módulos rapidamente quando necessário.
• USELVM: Procura por volumes LVM durante a inicialização; necessário se você usa LVM. Bem, eu não uso, provavelmente tu não usa, e podemos passar adiante.

INICIALIZANDO A REDE DO SISTEMA

Esta parte é importante para que tua rede funcione no Arch Linux, seja ela a cabo, wireless, 3G ou outra. A configuração que é feita neste setor do arquivo rc.conf só é aproveitável para mim em máquinas com conexão a cabo, pois sua instalação é muito mais fácil e simples do que uma sem fio.

• HOSTNAME: É o nome da máquina, sem a parte do domínio. Tu tens a liberdade de escolher um, contanto que só utilize letras, números e alguns poucos caracteres especiais como o hífen. Em caso de dúvida nesta parte, sem problemas, pode deixar o nome padrão.
• INTERFACES: Aqui você define as configurações das interfaces de rede. As linhas já presentes e os comentários explicam como deve ser feito. Se você não usa DHCP, tenha em mente que o valor da variável (a qual o nome representa o nome do dispositivo a ser configurado) é exatamente a linha de argumentos que você daria ao comando ifconfig se estivesse configurando o dispositivo manualmente através do terminal. Caso tu use o NetworkManager ou outro gerenciador de rede, apenas pule esta parte, assim como eu pulo.
• ROUTES: Você pode definir suas próprias rotas estáticas aqui. Para ter uma idéia de como fazer, veja o exemplo para um gateway padrão. Basicamente, você cria uma rota com os argumentos que passaria ao comando route add, se fosse fazer manualmente. Leia o manual do comando route (man route) se não souber o que escrever aqui, ou simplesmente deixe como está que tu não terás problemas e incômodos futuros com esta linha.
• NET_PROFILES: Ativa certos perfis de rede durante a inicialização. Perfis de rede são uma das maneiras mais convenientes de gerenciar múltiplas configurações de rede, e seu objetivo é substituir a configuração padrão INTERFACES/ROUTES que é ainda mais recomendada para sistemas que possuem apenas uma única configuração para toda a máquina. Se seu computador irá participar de várias redes distintas (um portátil, por exemplo) então você deveria dar uma olhada no diretório /etc/network-profiles para configurar alguns perfis. Lá você encontrará um arquivo de exemplo a partir do qual poderá criar novos perfis. Acredite, já entrei lá e encontrei um bocado de amostras boas para uso na configuração.

ATIVANDO E DESATIVANDO SERVIÇOS

Tal é a organização e a simplicidade desta distribuição que ela permite que, utilizando apenas sua última linha do rc.conf, por serviços para inicializar ou não, muito diferente do que vejo em outras distribuições (que aliás, sem ferramentas gráficas nestas acabo sofrendo um pouquinho. A variável DAEMONS funciona da seguinte forma: se houver um ponto de exclamação (!) antes do nome do script, ele não será executado. Se ao invés disso houver um arroba (@), então ele será executado em segundo plano (background), ou seja, a sequência de inicialização não irá esperar por um retorno do script (se falhou ou não) para poder continuar.

Normalmente você não precisa modificar nada aqui para que o sistema simplesmente funcione, mas definitivamente será necessário modificar essa lista quando você instalar algum serviço como o sshd (Terminal Remoto, uso de vez em quando), e quiser que ele seja carregado automaticamente durante a inicialização. Esse é basicamente o jeito Arch de lidar com o que os outros lidam utilizando-se de vários links simbólicos para um diretório init.d. Simples, não? Vale lembrar que a ordem em que os daemons são listados é importante pois é nessa ordem que eles são carregados. Por exemplo, dbus deve vir antes de hal, a menos que você queira ver algumas mensagens de erro durante a inicialização.

Como alguns devem ter percebido, minha fonte da vez foi o Wiki do Arch Linux. Apesar disso, fiz algumas pequenas mudanças e dei um toque um pouco mais “humano”, como faço em meus posts de Rock. Espero que este conjunto de posts já esteja sendo útil para quem leu, seja para testar o Arch, para usar ou apenas para observar seu funcionamento. A todos agradeço a atenção. Dentro de alguns dias irão iniciar os preparativos para o lançamento de meu projeto para a comunidade, com o objetivo de conseguir colaboradores para as mais diversas áreas de desenvolvimento dele. Entrarei em detalhes nos próximos posts.

Padrões e o Software Livre

Volto a escrever sobre um assunto um tanto problemático no open source. Garanto que posso mostrar um bocado de coisas boas deste tema com minhas simples palavras. Ou talvez não. Apesar das padronizações soarem pouca liberdade, elas possuem diversos pontos positivos, especialmente quanto à base de um sistema operacional e seus subsistemas (mais conhecidos como serviços). Quem jamais se incomodou com a falta de padrão na base de som de uma distribuição GNU/Linux, que atire a primeira pedra. Ainda mais os desenvolvedores externos ao UNIX, em outras palavras, programadores da plataforma Windows. O problema não fica somente no áudio, mas também nas bibliotecas gráficas (a velha guerra entre o Qt e o GTK) e até mesmo na área de games (diversas bibliotecas e motores trabalhando isoladas, como SDL, Allegro e Blender Game). Alguém aqui neste ponto irá dizer da tal liberdade de escolha. Até que tenho que concordar, o usuário deve ter liberdades de escolher os produtos que melhor lhe convir. Porém acredito que seria muito bom se houvesse um consenso quanto ao que estar “instalado de caixa” e o que pode ser habilitado opcionalmente. Não estou afirmando que o desktop livre é uma bagunça, pois muita coisa já mudou para melhor desde que comecei a usar um GNU/Linux, graças a freedesktop.org e seus bons projetos. Ele está conseguindo, aos poucos, garantir uma ótima interoperabilidade entre os mais diversos ambientes gráficos, com componentes como o HAL, D-Bus e Avahi. Isso significa que está começando a ter uma base em comum nas mais diversas “versões” ou distribuições Linux, seja ela com GNOME, com KDE, com XFCE… A freedesktop.org trabalha em conjunto com o LSB (Linux Standard Base), que define certos padrões para uma distribuição GNU/Linux. A LSB é um tanto controversa em alguns aspectos como o empacotamento de software em RPM (sendo que muitos usuários linux estão acostumados com o DEB, formato mais antigo que o citado anteriormente), porém em outros sai-se muito bem. Aliás, a fragmentação do gerenciamento de pacotes nas mais diversas distros é um grande e estressante problema. É algo que pode estragar a portabilidade de um software, dentro do mesmo sistema (no caso, no mesmo núcleo). Há o Smart e o Packagekit, que são projetos que caminham em direção à padronização de pacotes, especialmente num GNU/Linux. A partir destas iniciativas (um pouco revisadas, claro), não só as distribuições GNU/Linux, mas também o desktop livre caminhará para a convergência.

Certas Parcialidades…

Digito aqui no frio de Gramado (para quem não conhece, um município gaúcho da serra, muito conhecido pelo seu Festival de Cinema), porém com um certo conforto dentro de um aconchegante hotel. Por um bom tempo da semana, me detive a pesquisar sobre games, especialmente os produzidos para os consoles da Nintendo. Não, ainda não tive o privilégio de possuir um console deles, a não ser por meio dos famosos “famiclones” (pesquise esse termo no google que tu vais saber do que se trata), já bastante obsoletos na minha época de piá (não é tanto tempo assim, uns 10 aninhos atrás ). Em compensação, a maioria deles eu consigo emular por meio de minha máquina, o que é bem agradável e, diria também que barato. Claro que não rodo videogames como o GameCube ou até mesmo o Wii (até existem bons emuladores para estes mesmos – como o dolphin – porém é necessário um bom computador para rodar adequadamente os jogos), porém os que eu consigo (NES até N64, GameBoy até DS) já são suficientes para meu notebook. Claro que gostaria de rodar jogos da plataforma que uso (GNU/Linux), e até por isso estou trabalhando neste projeto de games, que ainda não revelo exatamente do que se trata. Não porque não há jogos bons (até porque há, e ótimos), e sim porque muitos em desenvolvimento necessitam de um “aditivo”, uma melhoria. Mudando de assunto, já não é de hoje que percebo uma parcialidade da faculdade na qual estudo sobre os produtos da Microsoft. É lamentável quando ocorre isso, ainda mais com uma empresa dessas, que costuma ser muito mais suja que outras concorrentes. Mas, sabe, não me incomodo, pois não dependo deles (por mais que tenha o Office instalado, posso me virar com o OpenOffice e/ou KOffice), e faço o possível para que eles não paguem minha conta (traduzindo em outras palavras, evitar o máximo possível de trabalhar dentro da Microsoft… existem tantas empresas boas, porque eu escolheria justo essa?). Essa semana passou-se mais um episódio desta parcialidade. Como mais uma campanha pró-Microsoft, o Student to Business, ou “Seja programador de nossos produtos e seja dependente deles”, houve uma grande propaganda sobre o tal. Puxa vida, porque não fizeram o mesmo quanto ao FISL? Sabe, me envergonha saber que a faculdade, que é anfitriã de um dos maiores eventos de tecnologia do país, envia tão poucos alunos para o fórum. Essa é mais uma das tendências da universidade. Uma pena. Uma instituição tão bem estruturada, mas, deixa para lá… pelo menos posso usar o Fedora lá (versão 10, meio desatualizado) e não me incomodam com as chatices da Microsoft. Assim, acabo sendo mais um estudante satisfeito (um pouco, nem tanto) com a PUCRS e, especialmente a FACIN.