A startup Litl, fundada uns dois anos atrás e contando com figurinhas fáceis do projeto GNOME, lançou em fim seu primeiro produto: um “webbook”, ou seja, um notebook voltado para o uso da web. Seguindo a filosofia de que “menos é mais”, o sistema operacional e o hardware foram simplificados para não ficar entre o usuário e a internet. O aparelho tem só 2GB de memória flash, usada primariamente para cache dos trocentos arquivos (por exemplo, fotos) armazenados remotamente numa conta hospedada pela própria Litl. O aparelho também se propõe a facilitar o compartilhamento de fotografias, links etc com contatos, embora eu tenha minhas dúvidas quanto a até onde isso vai servir para amigos que não tenham uma conta na Litl.

Uma das características mais interessantes do webbook é a possibilidade de dobrar o teclado para trás da tela, de forma que a ser possível apoiar o notebook “em pé” sobre armários em qualquer lugar da casa. Em nenhum momento o site sugere levar o notebook para fora de casa: é cozinha, jardim, quarto, e por aí vai. Até porque está claro que o computador não foi feito para trabalhar, e sim para estender a lista de eletrodomésticos da casa. (Por acaso eu mencionei que serve de despertador?) Mesmo assim o hardware é decente, com um processador Atom e 1 GB de RAM. O teclado é bem simplificado, e existe ainda um controle remoto para passar fotos e outras atividades mais simples. A propósito, em vez de uma conexão VGA, o aparelho tem uma conexão HDMI, pensando em ver fotografias da família na TV digital.

Na parte do servidor, a Litl usa e abusa de tecnologias consagradas como Google App Engine, Amazon S3 e Django. Os dados do usuários ficam todos no servidor, e são sincronizados continuamente e sem interferência. O sistema operacional é baseado no Ubuntu, com a plataforma GNOME e doses generosas de XULRunner e Clutter, sendo a maior parte do código escrita em JavaScript graças ao GJS (confira também meu artigo sobre o estado do JavaScript no GNOME). Mesmo com a forte presença de software livre, o código desenvolvido pela Litl é fechado, e não existe previsão de abertura. Vale a pena ressaltar também que o hardware, o software e o serviço remoto fazem parte de um mesmo pacote, não é possível usar um sem o outro ou vice-versa. (Confira também de o artigo de Lucas Rocha e o de C. Scott Ananian sobre os detalhes técnicos.)

Quando fiquei sabendo do lançamento no webbook Litl eu pensei “Droga, acabei de encomendar um netbook!” Mas, pensando bem, o Litl não é para mim. Para começar, eu não estou tão conectado à internet ao ponto de mover minhas fotos de meu computador para “a nuvem”. Segundo, não sou um consumidor tão ávido assim de tecnologia, minha televisão nem é digital. E por fim, estou procurando algo versátil, que eu possa fuçar e que sirva para trabalhar, e não um eletrodoméstico. Mas obviamente existe todo tipo de necessidade por aí, e imagino que o Litl vá conquistar seu espaço no nicho dos portáteis, competindo com Maemo/Symbian/Android/Moblin/Windows mas ao mesmo tempo estabelecendo um diferencial. De uma certa forma, a Litl está tentando fazer com seu webbook aquilo que a Asus tentou e não conseguiu fazer com seus primeiros EEE. Só espero que a interoperabilidade dos dados não seja neglicenciada.

O tema do WordPress que uso foi abandonado pelo autor, e recentemente terminei as atualizações a que me propus. Se você estiver procurando o que fazer, por favor confira se algo não está funcionando corretamente no blog. Obrigado!

So, you’ve probably seen the news: litl webbook released! It’s the result of heavy work of an awesome team! Our website has a lot of information about the product from a user perspective, so I thought it would be nice to bring an overview of the more technical aspects of the litl OS that I find specially interesting. Scott has written some technical notes about our OS too.

Javascript

Almost all UI code is written in javascript using our GObject introspection-based binding called gjs (using SpiderMonkey engine). It was a quite interesting learning experience to write a large amount of UI code in javascript. By the time we started, I think no one in the team had any real experience with javascript. So, it took some time until we all agreed on the javascript programming idioms (the flexibility of the language may “cause” a lot of inconsistencies…) and on how to better/correctly take advantage of its features. Most of what we agreed in terms of coding style is in the gjs style guide. Doing stuff in javascript (i.e. not doing the whole UI in C or any other insanity like this) allowed us to prototype, refactor, rewrite things much faster. And that was crucial for us because the ideas around the UI design changed a lot during the first months of development and we ended up rewriting large chunks of code several times on the way. Doing relatively large scale stuff in javascript definitely requires very clear and strong guidelines in order to keep the code base sane – maybe a bit more than usual.

GNOME & FLOSS stuff

The OS is heavily based on well-known open source projects. Some facts: it’s based on Ubuntu (with great support by Canonical) and the UI is all written with GNOME platform and co. As I said, almost all code is written in javascript using gjs. Most of the UI is Clutter-based. We have our own specialized window and compositing manager that was implemented with our use cases in mind. We’re definitely one of the projects with the largest Clutter-dependent code base. We use GTK+ in just a few places where we needed more complex widgets (i.e. text entry). The web browser is Gecko-based and it’s pretty much implemented as a XUL app running in a separate process than the OS chrome. We use Evince and Totem (as browser plugins), GStreamer, Network Manager, and others. One interesting fact about our development process is that, in the ~2 years of heavy hacking, we had to adapt to major changes in the upstream projects we base our OS on. So, since we started, we had to port our UI to Clutter 0.6, then 0.8, and finally 1.0; had to port gjs to use the then-new GObject introspection scanner; migrated from Network Manager 0.6 to 0.7; and maybe some other major changes that I can’t remember now. We contributed to those projects as much as possible during the process.

No storage, just caching

You probably noticed that the device has “only” 2GB of storage. That won’t sound strange if you see this from a “webbook perspective”. One of the ideas behind the product concept is that the device serves as a much improved window to the web. In other words, the device provides a simple and beautiful way to access web content – among other things. So, we are pretty much only using storage for local caching. We don’t really store any real permanent data on the device. And that brings some interesting challenges on how we implemented the OS. So we had to implement some smart ways to cache as much content as possible and expire the right bits at the right time so that the general experience is nice and smooth. Simple example: the OS provides a way to access all your Flickr photos and videos (which can be a lot of photos and videos btw) but we never permanently store anything on disk. We cache things like rss feeds, profile pictures of your litl contacts, a lot of your Flickr photos and videos, website favicons, installed channels, etc. Each type of content may use a different way of expiring items and all that needs to fit in the relatively small storage space we have. You can guess how fun it was to hack on this. Hacking on syncing was even more fun though :-)

Syncing

Another interesting aspect of the device is that each device is connected to a litl account on our servers and all your stuff (browser cards, channels, settings, contacts, etc) is always synced in our servers. That means if you lose your device and get new one, you would just need to connect your device to same account and all your stuff would be nicely restored. Additionally, multiple devices can be associated to same account. In that case, they will automatically share channels and other things. If you add channel card in one, it will automatically appear on the other. We spent quite some time working on our syncing infrastructure (client and server), dealing some relatively complex problems – especially when dealing with making UI immediately react to sync-related changes in the local and remote datastores. The server side syncing stuff (and other server-side features) is implemented with Google App Engine, some bits in Amazon S3 and Django.

Seamless system updates

The OS comes with a smart update system. No package management involved. No user action needed to get system updates. In practice, we download and install a new OS image and fetch your data again from litl servers while the system is idle. The update system falls back to current image in case something goes wrong with new OS images. The update system allows us to keep updating, adding features, fixing bugs, and then push those updates to our users in a burden-free way.

We had a lot of fun hacking on the litl webbook. It’s always great to work in a team full of very smart people. Definitely learnt a lot in the process. We still have a lot of work to do of course but I already feel very proud of what we’ve accomplished so far. Exciting times!

Update: Saying that the UI is 99,99% Clutter-based is not very accurate. It’s a bit less than that :-)

Eu tô há algum tempo ficando cada dia mais chateado com o Banco do Brasil. Apesar de usar GNU/Linux internamente, e aparecer na mídia como uma instituição aliada do software livre, o banco sempre foi um pé no saco pra quem quer usar softwares e protocolos abertos. A idéia de girico da equipe do BB de usar java para uma “solução de segurança” sempre me deixou sem entender. Por muito tempo isso me obrigava a usar software proprietário se quisesse usar o banco online. Resultado: eu não usava banco pela Internet até a Sun lançar o java como software livre.

Acontece que o navegador que eu uso atualmente não tem suporte a plugins java ainda (porque, claro, o plugin do Java não é um plugin normal, como todos os outros que já funcionam), e eu uso atualmente amd64, e, caso você não saiba, a ’solução de segurança’ do BB só funciona com 32 bits. Como todos sabem, java é portável.

Algumas coisas, como essa, eu consegui passar por cima. Por exemplo: eu estava um dia olhando uma propaganda do banco sobre recursos para o iPhone. Na hora veio na minha cabeça: mas, peraí, iPhone não tem Java! Como, então, se usa iPhone para acessar o banco? Óbvio: retira-se a solução de ’segurança’, que sempre foi uma estupidez inútil, e se permite fazer algumas operações pelo iPhone. Não entendo muito bem por que a cisma com o iPhone, hype é foda, mas de qualquer forma, eu obviamente pensei em fazer meu próprio iPhone! Aqui vai, como!

Instale o Midori, no Debian basta instalar o pacote ‘midori’. Abra o Midori e vá no menu ‘Edit’, opção ‘Preferences’, e na aba ‘Network’ mande o Midori se identificar como ‘Custom’. Adicione a seguinte linha no campo de texto:


Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1C25 Safari/419.3


Pronto, você já pode logar no BB online pelo Midori, como se fosse um iPhone. Ḿas pra eu acessar pelo meu navegador normal não pode, né, BB?

Nos últimos tempos, minha relação com o banco ficou mais complexa: eu recebo meu pagamento pelo trabalho que faço para a Collabora por transferência internacional, e isso faz de mim um exportador de serviços (que chique, hein?), o que me obriga a usar uma estrutura similar a de empresas no trato com o banco, incluindo usar o horrível, péssimo, mal feito e bugado “Gerenciador Financeiro aplicativo”. Feito na maravilhosa linguagem Java™, que como todos sabem é Write once, debug everywhere™.

Esse pedaço de fail é extremamente chato de mexer, muito complicado. A única coisa fácil que dá pra fazer nele é errar. Mas até funcionava no meu amd64 (a solução de segurança não tava nem aí que ela falhava). Acontece que no último mês eles mudaram a forma como isso é feito, e agora não funciona mais com amd64, então eu precisei usar uma vm 32bits pra fazer o que eu preciso fazer.

Como isso já está beirando o ridículo, e eu sei que a única coisa que me causa esses aborrecimentos é a incompetência técnica do Banco do Brasil, acho que chegou a hora de repensar definitivamente qual banco usar para minhas necessidades bancárias. Sugestões?

Depois de um comentário do Kov neste blog me mostrando que o Gnome-Shell está no Debian a pouco tempo, através deste POST em seu blog, me lembrei que a grande maioria dos softwares, só não me arrisco dizer todos, que estão nos repositórios do Debian, possuem um manual ou um README.Debian.

E o que isso tem haver com tornar o Gnome-Shell o ambiente desktop padrão do GNOME?

Bom foi lendo o README.Debian que eu aprendi como se faz da maneira certa.

No post anterior a este, eu dei uma dica de como instalar e fazer com que o Gnome-Shell fosse executado no ato do login do GNOME, mas venhamos e convenhamos, era uma baita gambiarra.

Era uma gambiarra por que ele fazia o gnome-shell executar quando o lgoin fosse feito e não que este fosse configurado corretamente para ser o ambiente desktop padrão, assim como o metacity/gnome-pannel são configurados normalmente.

Mas voltando ao ssunto, eu aprendi lendo o README onde está muito claro como isso dever ser feito.

Segue o trecho e o caminho para encontra-lo no seu sistema assim que seu gnome-shell estiver instalado:

A propósito, é bem encorajador

flamarion@arvore:~$ less /usr/share/doc/gnome-shell/README.Debian

…..

3. If you have enough corage…

GNOME Shell installs a .desktop file which makes it possible to make
it the default for your session, replacing metacity/gnome-panel. To
make it the default all you need to do is set the following gconf key
to ‘gnome-shell’:

/desktop/gnome/session/required_components/windowmanager

Here’s the gconftool command, if you’re feeling lazy:

$ gconftool-2 -t string -s /desktop/gnome/session/required_components/windowmanager gnome-shell

Não precisa ter medo, isso funciona.

Então esqueçam a dica do .gnomerc que dei anteriormente e usem a forma correta.

Caso não tenha facilidade de fazer isso pela linha de comando você pode fazer a mesma mudança a partir do “Editor de Configurações” que fica no menu Aplicações->Sistema->Editor de Configurações, no seu Debian.

E ele tem esta cara:

Modifique a chave selecionada para gnome-shell e terá o mesmo efeito que a linha de comando sugerida pelo README.

Espero que tenha ajudado, e obrigado Kov pelo comentário que fez no post anterior e me fez ler um pouco mais a respeito e fazer a coisa da maneira correta.

… de saber onde foi parar o código que o Katatudo prometeu por volta de 2004.

Pelo jeito vamos ficar sem, mesmo. Hoje em dia o Leonardo Cardoso, que nos tinha prometido que o trabalho estava sendo feito já saiu da empresa sem cumprir a promessa, e até a minha única esperança e que algo fosse sair, o Cristiano Anderson, parece já ter ido para pastagens mais verdes, também sem cumprir a promessa que fez =(.

Mas agora acho que não precisa mais, né? A propaganda já foi feita, a empresa já foi comprada, todo mundo já pôs o que queria no bolso, uma outra geração de gente pra ser enganada já entrou no mercado. Se esse fosse o único caso de cara de pau no software livre brasileiro eu ficava até feliz. Nossa vontade de querer acreditar em tudo, junto com nossa capacidade de esquecer de tudo bem rápido torna esse tipo de coisa possível. Também torna possíveis alguns discursos políticos muito engraçados, btw.

Há algum tempo eu venho usando o gnome-shell, mas venho compilando ele diretamente do git.

Por acaso, eu ja deveria saber que estava lá, tentei fazer a instalação via apt (aptitude) no Debian.

Infelizmente para a versão testing ele ainda não está disponivel, mas para minha felicidade estava disponivel no sid, e sem dependencias quebradas, ou seja, instala que é uma beleza.

Caso você use também o testing e queira experimentar o gnome-shell no seu Debian pode fazer o seguinte:

Adicione o sid/unstable no seu sources.list, deixando-o assim :

cat /etc/apt/sources.list

deb http://ftp.br.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.br.debian.org/debian/ testing main contrib non-free

deb http://ftp.br.debian.org/debian/ unstable main contrib non-free
deb-src http://ftp.br.debian.org/debian/ unstable main contrib non-free

Se preferir use sid onde está unstable e squeeze onde está testing, mas não vai fazer diferença.

Em seguida edite o /etc/apt/preferences, caso não exista crie e deixe dessa forma:

Package: *
Pin: release a=testing
Pin-Priority: 900

Package: *
Pin: release a=unstable
Pin-Priority: 500

Só para entender, o que fizemos foi o seguinte, adicionar o respositório da versão instavel do debian no sources.list junto com a versão de testes.

E para que, quando você fizer um aptitude safe-upgrade, upgrade ou dist-uprade, ele não assuma os pacotes mais novos como os atualizaveis, obviamente que estão na versão instavel, criamos o preferences onde colocamos uma prioridade maior para a versão de testes dizendo assim que os upgrades devem ser feitos a partir dessa versão.

E ai você vai me perguntar, como que eu instalo então o gnome-shell da versão instavel já que o sistema assume que a versão  de testes é a que prevalece?

É simples, você pode dizer ao aptitude que ele deverá buscar este pacote da versão instavel, da seguinte maneira.

Antes, é logico, você vai atualizar sua lista de pacotes com um:

aptitude update

E instale o gnome-shell assim:

aptitude -t unstalbe install gnome-shell

Coisa linda de Deus, vai baixar da sid só o gnome-shel e suas dependencias e instalar na sua versão testing.

Para ve-lo funcionando é bem simples, faça assim no seu terminal, com seu usuário mesmo:

gnome-shell –replace

Este comando vai te dar a próxima geração do ambiente de trabalho que o gnome trará na sua próxima versão, isso é bom caso você queira mudar para o gnome-shell quando atualizar seu gnome para o 2.30, ou 3.0 se assim for decidido.

Caso queira colocar o gnome-shell em backgroud para continuar usando o terminal é só usar o “&” no fim do comando, assim:

gnome-shell –replace &

E caso queira usar ele como padrão na inicialização pode criar o .gnomerc e lá dentro chamar o gnome-shell, algo assim:

flamarion@arvore:~$ cat .gnomerc
/usr/bin/gnome-shell –replace

Se o .gnomerc não existir, crie no seu home.

Lógico que deve existir uma maneira para que o gnome-shell seja seu ambiente padrão sem ter que usar o .gnomerc, mas eu ainda não sei.

Sei que assim funciona.

Se desejar usar o gnome-shell diretamente do git, na página oficial tem como fazer:

http://live.gnome.org/GnomeShell

Espero que curtam o gnome-shell o tanto que estou curtindo.

Semana passada fui no Latinoware e foi bastante interessante. Lá palestrei sobre nossa equipe de tradução do GNOME e tive algumas experiências interessantes:

• Foi bacana rever alguns e conhecer boa parte do pessoal do GNOME Brasil. Espero vê-los mais vezes;
• Também revi o Farid, que trabalha comigo no Archlinux Brasil, ficamos de conversar mais como acabei não podendo ir no último dia devido ao atraso do motorista que ia buscar a gente no Paraguay, não conversamos ;
• As palestras também foram legais: o Lício falou sobre o GNOME Love, eu falei sobre a equipe de tradução do GNOME para nosso idioma, o Binhara falou sobre o Mono, a Izabel e a Luciana falaram sobre o GNOME Women (eu infelizmente perdi essa palestra ), o Vinicius Depizzol falou sobre a experiência do usuário no GNOME e para finalizar o Tiago falou sobre personalização do GNOME. Um ótimo conjunto de palestras ;
• Foi legal discutir coisas, tanto técnicas como não técnicas, com as outras pessoas do GNOME e de outros projetos como o Fedora. Aliás esses eventos acabam proporcionando trocas de experiências que contribuem em muito com os projetos de SL. Aliás isso é uma das coisas mais importantes de eventos como esses e tenho que ser bastante grato à Fundação GNOME por me patrocinar e ter a oportunidade de fazer coisas como essa, além de poder participar do evento e conhecer mais pessoas;
• Depois de assistir uma palestra interessante sobre o Mono com o Binhara e depois de ouvir o Everaldo falar horas e horas disso, fiquei com vontade de aprender a programar nesse ambiente;
• Conversei com o João Sebastião sobre como podemos fazer a adequação do GNOME para a nova ortografia. Para corrigir algumas coisas nas versões antigas ele fez um script que pode ser bastante útil para agilizar nosso trabalho. Próximos capítulos desta trama serão divulgados aqui neste blog em breve ;
• Conheci o Paraguay, e embora este país tenha muitos produtos interessantes a venda ele tem a pior poluição visual que já vi;
• Não consegui ver as cataratas, aliás faltou tempo para isso ;
• Minha palestra não teve um grande público, mas acho que deu para passar a mensagem da equipe. O pdf aparecerá em breve por aqui;
• Foz do Iguaçu é uma cidade bastante esquisita: lá é úmido pra caramba, escurece bem tarde e isso me faz perder a noção do tempo;
• Não gostei muito de comida Baiana. Tem muita cebola. E eu odeio cebola. Aliás, a coisa que menos comi lá foi comida paranaense;
• A organização do Latinoware também deixou muito a desejar, já fui em eventos mais bem organizados e acho que o Latinoware também podia ser;
• Agradeço a fundação GNOME por me patrocinar, ao Leonardo por me indicar para palestrar e a Izabel, que correu atrás de tudo por lá (aliás, depois que organizei junto com amigos a ida do pessoal da minha faculdade pro FISL, aprendi a agradecer as pessoas que fazem acontecer);

É isso aí Que o próximo evento venha logo e que eu tenha a oportunidade de vê-los em breve.

Olá, internet! Hoje lancei o Vinagre 2.29.1, com features bem legais:

Conexões Reversas (tipo o modo listener do vncviewer):

Eu quero a ajuda de alguém para documentar esta feature:https://bugzilla.gnome.org/show_bug.cgi?id=597110

Possibilidade de mudar a profundidade de cores e usar compressão JPEG (com perdas):

E uma mini-toolbar no painel dos marcadores:

Leia o anúncio completo (inglês) em http://mail.gnome.org/archives/gnome-announce-list/2009-October/msg00069.html

Se você quer ser informado sobre novidades assim que elas acontecem, siga-me no twitter ou identica.

A propósito, seria interessante se alguém criasse um repositório PPA (Ubuntu) para o vinagre instável. Se você tá interessado, mande um email pra mim!

Bem bacana a nova versão da animação em massinha sobre Software Livre. Nela é possível escutar com muito mais nitidez a narração da história sobre o software livre, junto com uma nova musiquinha de fundo. Apesar de gostar mais da trilha sonora da primeira, o resultado final dessa nova versão ficou muito legal e vale a pena compartilhar. Parabéns ao Kretcheu pela iniciativa e ao Ary Favero Jr pela locução! :-)

Para que todas/os possam comparar e tirar suas próprias conclusões, segue abaixo as duas versões:

VERSÃO 0.2

<object data="http://vimeo.com/moogaloop.swf?clip_id=5863277&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1" height="270" type="application/x-shockwave-flash" width="400"> <param name="allowfullscreen" value="true"> <param name="allowscriptaccess" value="always"> <param name="src" value="http://vimeo.com/moogaloop.swf?clip_id=5863277&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1"> </object>

Software Livre - Animação em massinha from kretcheu on Vimeo. Adaptação do Kretcheu e Ary Favero Jr.

VERSÃO 0.1

<object data="http://www.youtube.com/v/UvWRhnc_77Y&amp;hl=pt-br&amp;fs=1&amp;" height="344" type="application/x-shockwave-flash" width="425"> <param name="allowFullScreen" value="true"> <param name="allowscriptaccess" value="always"> <param name="src" value="http://www.youtube.com/v/UvWRhnc_77Y&amp;hl=pt-br&amp;fs=1&amp;"> <param name="allowfullscreen" value="true"> </object>

Versão original de Aurélio Heckert e Rozane Suzart.

Em um conferência de Linux no Japão, a Microsoft coloca (de propósito ou não) um ponto de venda do Windows7 em frente ao local. Nosso amigo Linus Torvalds tira uma onda e vai lá “prestigiar” o lançamento.

Fonte da foto.

Quem acompanhou a hashtag #emsl no identi.ca já tem uma idéia de como foi o Encontro Mineiro de Software Livre este ano. Para quem esteve lá, resta a certeza de como foi maravilhoso!

O EMSL é o evento que acontece anualmente em terras mineiras para promoção do Software Livre, como o próprio nome já diz. Este ano, foi decidido realizar o evento na cidade de Itajubá, no sul de Minas Gerais. IMHO, não houve melhor coisa! A comunidade Itajubense recebeu o evento de braços muito abertos e não poupou esforços para fazer do evento um grande sucesso. Agradecimentos especiais ao Júlio Cardoso, que aceitou o desafio de levar o evento para lá!

Palestras e mini-cursos: Foram muito legais, entre o que assisti, chamo a atenção especialmente para a do Professor Cláudio Kirner, que soube explicar bem o assunto no pouco tempo que tinha. Com toda certeza é um dos maiores conhecedores do tema que falou: realidade aumentada.

Fora as palestras: Muita diversão, conversa e socialização, do início ao fim do evento. E como todo bom mineiro, fizemos isso quase sempre na mesa de um bar flambando bebidas. Os assuntos: Todos aqueles que nerds adoram. Meus agradecimentos especiais ao Lincoln, farrista que foi o responsável pela “diplomacia” entre times e pessoas durante o evento e a Júlio Neves, pelas piadas e “causos”, ele é mineiro de coração e de fígado também! Ao Cascardo, GNU! Por ter insistido para que eu fosse ao evento. Se tivesse deixado de ir, teria perdido muito.

A cidade: Itajubá é uma cidade muito bonita, limpa, com pessoas agradáveis, mulheres lindas e inteligentes.

Comunidade local: Muito acolhedora, pessoas excepcionais. <miguxo>Por mais que eu fale, não vou conseguir expressar tudo</miguxo>. Lá, todos estão todos prontos para “2 dedim de prosa”. Júlio Neves que o diga =)

Organização e sentimento geral: Apesar de toda a discussão que aconteceu nos meses de organização do evento, acredito que no final, todas as expectativas foram superadas. Com todos que conversei, ficou o sentimento: Foi inesquecível.

Meus agradecimentos a todos que fizeram o evento acontecer, tanto na lista quanto durante o seu acontecimento.

Acompanhe fotos logo logo no site do evento

This post could be called “Ideas for GNOME Activity Journal during Zeitgeist Hackfest” too.

Every time I see a list of recent documents in some application, I never see what I am looking for. Checking the recent files on the Places menu of gnome-panel gives me nothing more than some links to pictures or text files I opened some time ago which are far from relevant for me right now. The same happens for similar lists in Gedit menu or other applications.

This very approach is initially being used as default for the new GNOME Activity Journal, which is the application who shows data from the Zeitgeist library. In general terms, the Activity Journal is a huge list of everything you did in your computer, ordered by time.

While having all this information is very useful, displaying it is nothing but tricky. Just listing tons of files sequentially won’t help anyone for finding the file you opened yesterday because the relevance “dimension” is missing.

If I just open some files and close them very quickly, than they shouldn’t be more relevant than the document I worked on for three hours. The photos I saw from my last travel shouldn’t occupy all the list of recent files, as I just spent some seconds in each of them.

Group similar activities can be interesting too. Facebook does that for news feeds and it works quite well. Seeing all the photos from my last travel is only one activity for me. Also, people open and close documents all the time. Make important documents easily accessible is more important than list the last closed one.

Na noite de outubro 16 de 2009 aconteceu a primeira reunião da equipe de traduções do GNOME Brasil já sobre a nova coordenação do Rodrigo Flores. Infelizmente perdi o início da reunião mas o Rodrigo fez um excelente trabalho em resumir os pontos discutidos e enviou para todos da lista de discussão. O que segue abaixo é o conteúdo deste e-mail, formatado por mim para (espero) melhor destacar os assuntos discutidos:

1. Manter padrões:
   • Uma das coisas que as vezes falhamos é em manter os padrões. As vezes um tradutor menos experiente acaba colocando maiúsculas onde não deve e isso sai do padrão. O que podemos fazer é criar uma página no wiki com os padrões e ir discutindo eles aqui na lista. Nomes de aplicativos que podem confundir a gente coloca também coloca em tabela.
     

     Ex: | Eye of GNOME | Visualisador de Imagens do GNOME |

2. Adequação a nova ortografia:
   • Inicialmente houve 3 alternativas (uma delas meio “inviável):
     • Revisar tudo manualmente (essa é a inviável)
     • Script que corrige palavras, pegando as que mais aparecem (isso deixaria só metade corrigido).
     • Rodar um corretor ortográfico (pareceu ser a mais viável).
   • Há corretores ortográficos já atualizados como o Aspell [1] e dicionários online com a nova ortografia [2]. O Vladimir também sugeriu um dicionário de papel da ABL com a nova ortografia [3].
   • Para quando faremos essa mudança ? Uma sugestão do John Wendell é termos tudo traduzido para o GNOME 3.0 (que pode ser lançado em 5 meses ou 11 meses) e anunciar isso como uma feature.
3. Regra de crédito de autoria:
   • Decidimos que alguém só pode por seu nome no crédito de autoria se ele traduziu/arrumou o fuzzy de pelo menos 10 mensagens. Mas mesmo que se traduza menos que isso, o nome de quem traduziu vai pro Last Translator e pra mensagem de commit. Esse número pode ser discutido, mas o povo da reunião concordou com 10.
4. String Freeze Break:
   • O John Wendell esclareceu para os presentes (inclusive para mim) o que era o String Freeze Break (e por que alguns módulos no String Freeze apareciam novas mensagens):
     • [22:36:19      ] rodrigoflores_, deixa eu explicar
     • [16 22:36:31] isso só acontece quando o programador *erra*
     • [16 22:36:56] mas por default as strings novas só aparecem *se* forem aprovadas
     • [16 22:37:17] a pessoa pede, se for aprovado, o cara faz o commit
   • Uma sugestão que ele deu, e que eu concordo é que todos assinem a i18n [4]. Lá vocês ficam sabendo o que foi aprovado e o que não foi e etc.
   • Precisamos também escrever algo no Wiki sobre isso. O Flamarion ficou encarregado disso .
5. Mudança nas “regras” de promoção:
   • Sugeri adicionarmos o item “Ter traduzido algo não trivial” na regra de promoção tradutor -> revisor. Um dos objetivos pretendidos disso é tentar fazer com que tradutores já em fase de serem promovidos traduzam mais coisas não triviais. A alteração não foi aceita, e os motivos disso foram que traduzir quantidade é diferente de traduzir com qualidade e que, revisores só devem aceitar se acharem que o cara é realmente para termos a confiança de que se o cara mandou pode subir pro repositório sem dor de cabeça. Como quase todo mundo na reunião topou, fica a mudança rejeitada.
6. Tradução via Web:
   • Uma coisa que eu pedi que todos pensássemos sempre é em como melhorar nosso processo de tradução e nossas ferramentas e uma das coisas que vem aparecendo é a tradução online. O que eu quis salientar é que, IMHO, se isso existir, sou a favor que funcione como é no DL, onde o cara reserva, só ele mexe e depois disso ele marca como pronto. Uma coisa que me contaram (John) e que eu não sabia é que já existem planos para isso ser integrado no DL. Então me dei por satisfeito.
   • Uma coisa levantada nesse tópico (e em alguns pontos do resto da reunião) é que não temos muita documentação para iniciantes. Seria legal se tivéssemos Screencasts, e mais coisa no Wiki que ajude aos novos tradutores. Talvez uma seção “Comece Aqui” já fosse bom. O Flamarion sugeriu uma reunião na qual discutiríamos somente sobre o Wiki. Sou a favor disso e por mim já podemos marcar a data .

Pontos extras (que eu esqueci de comentar)

• Tradução incremental de documentações grandes:
  • Algumas documentações como o Anjuta são grandes e difíceis de serem traduzidas. Não seria bom se traduzissemos 50 ou 100 strings de cada vez e isso fosse revisado, submetido e a tradução continuasse, ao invés de se traduzir tudo e revisar tudo de uma vez? Isso deixaria o tradutor/revisor mais atencioso e podendo trabalhar aos poucos (isso obviamente pode ser feito por ele mesmo sozinho, mas acho que uma revisão externa sempre ajuda, além do que evitaria ter que corrigir erros recorrentes que estão na tradução inteira).
• Revisão obrigatória para módulos grandes:
  • Alguns módulos grandes (anjuta e evolution) tem muitas mensagens e um erro ou outro pequeno sempre tem mais chance de aparecer independente do tradutor e da revisão que ele mesmo acaba fazendo (independente se ele é tradutor, revisor ou coordenador). O que eu proponho é que essa revisão seja obrigatória. Isso certamente vai atrasar um pouco o trabalho mas acho que vai melhorar bastante nosso processo.

1. http://leonardof.org/2009/07/05/dicionario-para-aspell-agora-com-o-acordo-ortografico/pt/
2. http://www.priberam.pt/DLPO/
3. http://www.jacotei.com.br/dicionario-escolar-da-lingua-portuguesa-academia-brasileira-de-letras-letras-academia-brasileira-9788504011883.html?ordenarpor=3
4. http://mail.gnome.org/mailman/listinfo/gnome-i18n
5. http://mail.gnome.org/mailman/listinfo/gnome-pt_br-list

Se você tiver alguma dúvida, sugestão, bronca ou está interessado em ajudar com as traduções do GNOME (e não estou falando de traduzir para o Ubuntu ou qualquer outra distribuição), não use a seção de comentários deste blog, mas sim se cadastre na lista de discussão[5].

Após algumas semanas do lançamento do GNOME, já é possível utilizar a versão mais nova desse ambiente de Desktop no Archlinux.

Você pode conferir as notas de lançamento neste link. Alguns módulos, como o GDM por exemplo, estão bastante modificados e um dos principais pontos fortes desta nova versão é que muitas dependências de bibliotecas foram removidas de vários módulos preparando terreno para a versão 3.0.

Além disso, vários aplicativos foram melhorados e há novas features adicionadas em muitos deles. Vale a pena conferir.

Nossa, quanto tempo que não escrevia no meu blog em português!!! Muitas coisas aconteceram desde o meu último post, mas invés de descrever tudo aqui, convido a todos os interessados a dar uma “bizoiada” no meu blog em inglês!

Então, a vida está uma correria só e depois eu volto aqui prá falar mais detalhes sobre a correria toda. Só queria mesmo avisar a todos que o Planeta GNU/Linux Brasil ficou fora do ar por um tempo devido a problemas com o planetplanet, o programa responsável por gerar as notícias e agregar tudo na página web.  O problema foi com uns feeds que não estavam mais validando e o código do planetplanet “quebreva”!

Solução: joguei um WordPress mesmo com um plugin chamado FeedWordPress especializado em tornar o WordPress em um agregador de notícias. Tem até uma interface web para adicionar os feeds e tal!

Bem, atualizem o feed do Planeta e depois eu volto com mais notícias!

Ops! praticamente três meses sem postar nenhuma novidade. Porém não tinha como deixar passar em branco este post… está semana estarei de volta as atividades e compartilhando as novidades!

Perceba que o código e bem tosco, porém divertido! o uso do return com o método void main() foi forçar a barra!

Tenho que adimitir que a revista Info Exame sempre deu uma certa atenção ao Ubuntu, até mais que a outras distribuições. Mas ela é uma revista de informatica e é bem generica.
Na edição ela cometeu uma gafe(por ela podemos dizer o diagramador/ilustrador/ou seja lá que for que faz isso) que pode ser facilmente explicada mas o que não é uma boa justificativa a um erro desse nivel.

Confundir ubuntu com macos em um macbook é demais, não?

Resolvi criar uma ferramenta para me ajudar a fazer hardening de servidores linux e facilitar a minha vida no trabalho. Assim nasceu o hntool (hardening tool), uma ferramenta escrita em python cujo objetivo é fazer uma análise simples do servidor e dizer quais as falhas de segurança que existem.

Todas as falhas são niveladas de acordo com risco que podem causar ao servidor. Falhas leves (low), médias (medium) e graves (high). Além destas categorias há mais duas: ok e info.

A ferramenta ainda está em um estágio bem inicial, mas resolvi compartilhá-la logo para ajudar aqueles que querem contribuir com algo e, claro, acelerar o desenvolvimento.

Algumas características:

• Criei uma estrutura bem modular, baseando-me em outro projeto que mantenho: o namcap. Acredito que com essa estrutura fica muito mais fácil manter e contribuir com o projeto.
• Não quero que o hntool realize nenhum hardening automaticamente. Quero apenas que ele me avise das falhas que existem. A decisão sobre o que (e como) fazer para consertar a falha cabe ao administrador do sistema.
• A intenção é fazer com que o hntool sirva para qualquer distribuição, mas no momento eu só tenho testado no Arch Linux.

Usando o hntool

Para testar o hntool é fácil. Baixe-o daqui e descompacte-o. Depois é só entrar no diretório descompactado e rodar:

# python hntool.py

Sim, você só precisa do python.

Segue um exemplo do resultado do hntool (clique para ampliar):

Acho que deu para entender onde quero chegar, né?

Como contribuir

Você pode contribuir com o hntool de diversas formas: enviando código, patchs, reportando bugs e pedindo recursos. Tudo isso pode ser feito através do bug tracker do github ou enviando um email para contato arroba hugodoria.org.

Todo o código do projeto está disponível no github. Para baixá-lo e gerar seus patchs faça:

$ git clone git://github.com/hdoria/hntool.git

$ cd hntool

(faça suas mudanças no código)

$ git commit -a

$ git format-patch master

Isso irá criar um patch no formato do git. Dessa forma fica melhor para eu aplicá-lo.

A ferramenta também está precisando de um ícone simples e bonito. Sou um zero à esquerda quando se trata de desenho e totalmente incapaz de fazer algo decente. Fica aí a dica. :P

Estrutura modular

Como falei, resolvi criar o hntool de forma modular. A estrutura de um modulo é, mais ou menos, assim:

import os
 
class rule:
	def short_name(self):
		return "ssh"
	def long_name(self):
		return "Checks security problems on sshd config file"
	def analyze(self):
		check_results = [[],[],[],[],[]]
		ssh_conf_file = ['/etc/ssh/sshd_config', '/etc/sshd_config']
 
		for sshd_conf in ssh_conf_file:
			if os.path.isfile(sshd_conf):
				fp = open(sshd_conf,'r')
				lines = [x.strip('\n') for x in fp.readlines()]
 
				# Checking if SSH is using the default port
				if 'Port 22' in lines or '#Port 22' in lines:
					check_results[1].append('SSH is using the default port')
				else:
					check_results[0].append('SSH is not using the default port')				
 
				# Closing the sshd_config file
				fp.close()
 
		return check_results
	def type(self):
		return "config"

Explicando melhor:

• short_name(self): Uma string contendo o nome curto do modulo. Ele será usado, por exemplo, na hora de listar todos os módulos existentes (hntool -l).
• long_name(self) : Aqui é a descrição do módulo. Também será mostrada na listagem dos módulos.
• analyze(self): É aqui que fica o código de verdade. O resultado desse método deve ser sempre uma lista com 5 elementos, que correspondem aos níveis de segurança encontrados - ok, info, low, medium e high, respectivamente.
• type(self): Cada módulo será de um tipo. "files" para módulos que lidam com arquivos de texto simples(/etc/passwd, por exemplo) ou de configuração. "services" para módulos que lidam com serviços.

Há, também, um arquivo README explicando mais detalhes sobre o hntool. Obviamente, ele será melhorado com o tempo.

Bem, pessoal. É isso. Estarei sempre postando novidades desse projeto à partir de agora. :)

Recentemente precisei "consertar" um portal hackeado, que usava o Joomla como CMS. Isso me levou a pesquisar mais sobre a segurança do mesmo e perceber que ele não é nada bom neste quesito.

Durante minha pesquisa encontrei o OWASP Joomla Vulnerability Scanner, um script capaz de:

• Detectar a versão do Joomla, PHP e do SO
• Procurar falhas de segurança no Joomla e em seus componentes
• Gerar relatórios em texto e html
• Atualizar sua base de vulnerabilidades

Requisitos

Para usar este scanner você só precisa de: perl, perl-libwww, perl-www-mechanize. Todos estão disponíveis nos repositórios das principais distribuições. Para instalá-lo no Arch faça:

# pacman -S perl perl-libwww perl-www-mechanize

Ah! E precisa, obviamente, do próprio scanner. É só baixá-lo daqui e descompactá-lo.

Usando o OWASP Joomla Vulnerability Scanner

O uso básido do scanner é:

$ ./joomscan.pl  -u http://url-do-joomla

O joomscan te mostrará informações como:

Target: http://url-do-joomla

Server: Apache/2.2 (Debian) PHP/5.2.6-1+lenny3
X-Powered-By: PHP/5.2.6-1+lenny3

## Fingerprinting in progress ...

~1.0.x htaccess.txt revealed [1.0.13 - 1.0.15]
~1.0.x joomla.javascript.js revealed [1.0.13 - 1.0.15]
~1.0.x moscode.xml revealed [1.0.0 - 1.0.13]

* Deduced version range is : [1.0.13 - 1.0.13]

## 9 Components Found in front page  ##

com_frontpage     com_content
com_rsgallery2     com_docman     com_contact
com_search     com_banners     com_poll
com_rss

Vulnerabilities Discovered
==========================

# 1
Info -> Generic: htaccess.txt has not been renamed.
Versions Affected: Any
Check: /htaccess.txt
Exploit: Generic defenses implemented in .htaccess are not available, so exploiting is more likely to succeed.
Vulnerable? Yes

# 2
Info -> Core: Authentication Bypass Vulnerability
Versions effected: Joomla! 1.5.3 <=
Check: /administrator/
Exploit: Backend accepts any password for custom Super Administrator when LDAP enabled
Vulnerable? Yes

# 3
Info -> CoreComponent: com_banners Blind SQL Injection Vulnerability
Versions effected: N/A
Check: /components/com_banners/
Exploit: /index.php?option=com_banners&task=archivesection&id=0'+and+'1'='1::/index.php?option=com_banners&task=archivesection&id=0'+and+'1'='2
Vulnerable? Yes

E por aí vai. Útil, não?

Para ver as outras opções do joomscan rode-o assim:

$ ./joomscan

Ou visite a página do projeto.

Don’t know how? Here are some ideas:

http://live.gnome.org/PromoteTwoPointTwentyEight

I just added this banner in my blog.

No meu GNOME, um dos aplicativos mais executados é com certeza o mensageiro instantâneo Gajim. Atualmente, tenho gostado bastante de alguns recursos, miguxos bem legais de usar. São os recursos de “Humor”, “Atividade” e “Sintonia” que estão disponíveis quando usando um servidor Jabber que implemente o PEP.

Ativando os recursos:

Recurso de Humor:

Recurso de atividades:

Recurso de sintonia:

Como já foi dito, para poder usar os recursos é necessário ter uma conta Jabber em um servidor que implemente o PEP. Não vale ser e-mail do GMaill, pois o Google não implementou no seu servidor o PEP. Caso não tenha uma, é possível criar uma no próprio Gajim, ou em outro client de XMPP, como o Empathy. Para isso é só ir em “Editar > Contas > Adicione”

Em servidor coloque “jabber-br.org”, avance e escolha um usuário e senha. O servidor Jabber-br é muito bom e administrado pelo amigo Cascardo.

Caso não saiba nada sobre o assunto de Jabber/XMPP recomendo ler o ótimo artigo da AmandinhaKee (aka) Amanda-GNOME.

Obs: Obrigado ao Otubo, por me permitir divulgar seu gosto musical e endereço Jabber.

Atualização: Muitas pessoas me perguntaram sobre o transportes do Gajim para o MSN e outros. Eu indico para leitura este artigo aqui.

Nos ultimos dias o Ubuntu Brasil passou por 3 votações[1][2][3] que faziam parte da escolha dos novos membros do nosso Conselho Comunitário, todos os membros oficiais do Ubuntu tinham direito de voto.
Como toda eleição, essa não foi diferente e tivemos alguns problemas que foram contornados e finalmente tivemos a nova gestão escolhida.

Os novos membros do conselho são:

Em nome do conselho gostariamos de parabenizar os eleitos, e ao Fábio que está no 3o mandato, e esperamos que o novo conselho cheio de energia e vontade transmita esses sentimentos ao Ubuntu-BR.

Olá, pessoal. Ontei lancei o o vino e vinagre 2.27.90 (ou 2.28 beta 1). Novidades desde a versão 2.26:

Vino

• Não usa mais libgnome (usa agora libegg)
• Não usa mais libglade (usa agora gtkbuilder)
• Nova opção (GConf) para desabilitar a extensão XDamage. Veja #533613.
• Telepathy tubes: Permite você compartilhar seu desktop com um contato do Empathy.
• Várias correções pequenas.

Vinagre

• Novo sistema de plugins. Para implementar um novo protocolo, basta escrever um plugin.
• Telepathy tubes: Permite você controlar o desktop de um contato do Empathy.
• Novas opções de linha de comando: –fullscreen e –vnc-scale.
• Captura de tela pode ser salva em vários formatos.
• Barra de ferramentas no modo tela cheia é centralizada.
• Applet do painel é opcional. Desative com a flag –disable-applet no configure.
• Novo plugin para SSH *extremamente básico*. Ative-o com a flag –enable-ssh no configure.
• Usa GtkBuilder em vez de Glade.
• Suporta a autenticação MS-Logon do UltraVNC (precisa do gtk-vnc 0.3.9)
• Várias correções pequenas.

Falando em vinagre, está planejado para a versão 2.30 (ou 3.0) um novo plugin RDP, para acessar máquinas Windows. Estou esperando um amigo que me prometeu que escreveria um widget gtk+ para isso (conceito similar ao gtk-vnc). É Jorge, tô falando de você

Se puder, por favor, teste esta versão e reporte bugs e regressões, visto que o código mudou muito desde a última versão.

Ah, devido a estas mudanças, alcancei a marca de 1000 commits (!!) de acordo com o CIA.vc.

During the first days of July, I participated my very first GNOME European Conference, this year in Gran Canaria. It was just awesome meet the people I only knew before trough emails and IRC, and see all the Latin American Complot again!

Besides the talks and discussions (and the tripping around the island!), most of the time the GNOME Art team spent was in the hacking rooms, working on icon drawings, user interfaces mockups, new ideas for streamlining the desktop and coding the new website layout.

As a work in progress, some changes in the website design appeared while I was putting the new content in the layout (and this still needs to be finished!). The original one Lucas Rocha announced is becoming this (feedback is welcome!):

The plan is to release the beta website together with GNOME 2.28. For this, a lot of work needs to be done, including all the teams — content, design and CMS. We got a bit late in the schedule, but we can still get everything ready in time.

If you want to make history and help the GNOME website development, subscribe the marketing list (for the content and design areas) and the web mailing list for the plone implementation and introduce yourself .

One day, you’re writing code, packaging and translating it, administering systems and giving talks about free software. The next day, you realise you want to go to Law school.

It does not feel any different from starting all over. Fortunately, it feels like it is soon enough.

So yeah… I guess I’ll have to take back what I said about clearing the accounts backlog until the end of the weekend, even though I’ve already gone through more than half of it.

Why? Quite simple. My hard disk finally died, after a couple of months spitting out I/O errors and corrupting filesystems all around.

Oh well…