Conforme o POST do dia 05/07/2008, aconteceu em Recife a segunda edição do ESOL nas dependências do CEFET/PE. o evento teve duração de três dias e foi muito legal. muita gente envolvida resultou num evento super bacana! infelizmente por estar em semana de RELEASE na empresa que trabalho, não tive como comparecer assiduamente ao evento, e sem falar da correria e um principio de gripe que me deixou com a garganta super debilitada, fui ao evento ministrar a palestra sobre “Colaborando com o GNOME”. fiquei surpreso com a quantidade de pessoas e também um interesse visivel por alguns que estavam presentes, tentei passar as coisas legais e uma mensagem sobre a comunidade GNOME-BR. agora e esperar que breve alguns estejam presentes na lista do GNOME-BR e também colaborando com o projeto.

• Download do SLIDE

Há algum tempo eu fiz um tutorial mostrando como criar pacotes para o Arch Linux. O tutorial serve para a maioria dos pacotes, mas quando se trata de algo usando svn ou cvs o procedimento é um pouco diferente.

A diferença é, basicamente, em algumas linhas do PKGBUILD. É preciso prestar atenção nas variáveis conflicts, provides, svntrunk e pkgver.

De maneira geral um PKGBUILD para svn é assim:

# Contributor: Seu nome

pkgname=nome-do-pacote-svn
pkgver=versão
pkgrel=release
pkgdesc=”Descrição do pacote”
arch=(’arquitetura’)
url=”url do software”
depends=(’dependencias’)
license=(’Licensa’)
source=()
md5sums=()
provides=()
conflicts=()

build() {
intruções de compilação
}

O arquivo é bem simples e de fácil entendimento. É basicamente atribuição de variável. De qualquer forma vou fazer uma melhor descrição de cada campo.

# Contributor: Esta primeira linha do PKGBUILD não é obrigatória. Ela é usada apenas para mostrar quem criou o PKGBUILD e seu email (que será utilizado para troca de informações, sugestões, dúvidas etc). Apesar de não ser obrigatório, este campo é praticamente um padrão entre os empacotadores. Exemplo:

# Contributor: Hugo Doria <hugodoria at archlinux-br.org>

pkgname: É aqui que você coloca o nome do pacote. Exemplo:

pkgname=billreminder-svn

ou

pkgname=billreminder-cvs

NOTA: Perceba que você precisa adicionar os sufixos svn ou cvs no nome do pacote. Isso serve para diferenciar os pacotes normais dos de versões em desenvolvimento.

pkgver: Aqui fica a versão do programa que está sendo empacotado. Como se trata de uma versão em desenvolvimento esta variável não tem número fixo e muda constantemente. Tente sempre colocar a data ou o número da revisão aqui (no final do tutorial há uma dica de como fazer isso).

pkgver=4098

pkgrel: Aqui fica o release do pacote. Em pacotes svn e cvs esta variável nem tem tanta importância. Ela geralmente será 1 já que o pkgver muda constantemente.

Pkgrel=1

pkgdesc: Aqui é a descrição do software. Exemplo do billreminder:

pkgdesc=“small and quick accounting application designed to allow for easy tracking of bills”

Só duas observações:

• A descrição tem que ser em inglês.
• E você não deve colocar o nome do pacote na descrição também. Seria errado colocar a descrição desta forma:

pkgdesc=“Billreminder is a small and quick accounting application designed to allow for easy tracking of bills”.

Foi decidido que o nome do pacote não entraria na descrição do mesmo para facilitar a visualização no pacman e não causar duplicidade.

arch: aqui é a arquitetura para a qual o software está disponível. Você deve por cada uma entre aspas simples. Exemplo:

arch=(’i686′ ‘x86_64′)

url: Aqui você coloca o endereço da página do programa que você está empacotando.

url=”http://billreminder.sourceforge.net/”

depends: Esta é uma das partes mais importantes do PKGBUILD. É aqui que você vai colocar todas as dependências necessárias para que o programa funcione. Cada dependência deve ficar entre aspas simples e você pode adicionar quantas dependências forem necessárias.

Supondo que você esteja criando um pacote para um programa que dependa do python, firefox, e thunderbird a variável ficaria assim:

depends=(’python’ ‘firefox’ ‘thunderbird’)

E no caso do billreminder:

depends=(’python-pysqlite’ ‘python-notify’ ‘dbus-python’ ’setuptools’ ‘desktop-file-utils’ ‘pygobject’ ‘pygtk’ ‘pil’ ‘perlxml’)

Para descobrir quais dependências um determinado programa tem você pode visitar o site do mesmo, usar o comando ldd ou o namcap (uma ferramenta própria do Arch para isso).

makedepends: Aqui você coloca as dependências necessárias para se criar o pacote. Por exemplo, para se criar um pacote de uma versão cvs é preciso, claro, que o próprio cvs esteja instalado. Exemplos:

makedepends=(’cvs’)

ou

makedepends=(’subversion’)

NOTA: Não coloque aqui as dependências necessárias para que o software funcione. Faça isso na variável depends.

License: Aqui você coloca licensa do programa. O Arch se preocupa bastante com isso e você deve prestar muita atenção aqui. Exemplos:

license=(’MIT’)

ou

license=(’GPL’)

source: aqui fica o caminho para o source do pacote. Como em um pacote svn ou cvs não existe um arquivo de source em si esta variável deve ficar em branco. Exemplo:

source=()

md5sums: Segue o mesmo princípio da variável acima.

md5sums=()

NOTA: Mesmo vazias estas duas variáveis devem estar presentes no PKGBUILD.

provides: Esta variável serve para definir que o “pacote-svn” provê  “pacote” também. O billreminder-svn, por exemplo, provê billreminder. Isto serve para que programas que precisem do billreminder, por exemplo, possam reconhecer que ele está instalado no sistema. Dessa forma dependências quebradas são evitadas. ;)

Exemplo:

provides=(’billreminder’)

conflicts: Aqui você diz quais os pacotes que conflitam com o seu. Um meupacote-svn conflita, por natureza, com meupacote. Exemplo:

conflicts=(’billreminder’)

_svntrunk: Aqui você coloca a url da árvore svn que você quer baixar

Exemplo:

_svntrunk=https://billreminder.svn.sourceforge.net/svnroot/billreminder

_svnmod: Aqui você coloca o diretório onde será armazenado o conteúdo do trunk

Exemplo:

_svnmod=billreminder

NOTA: O _ no início das variáveis indica é um padrão que é usado para indicar que elas são variáveis customizadas, ou seja, que não são parte da estrutura real de um PKGBUILD. Você pode criar quantas quiser, mas só quando for realmente necessário.

build(): Aqui dentro você vai colocar todos os comandos necessários para se compilar o pacote. Geralmente você coloca os mesmos comandos que usaria para compilar o pacote normalmente.

Se você iriar ./configure; make; make install então é isso que você vai colocar dentro da função build(). Se você usa ./arquivo.sh –install-and-do-it-now, então é isso que você deve colocar.

De uma maneira geral o procedimento para svn/cvs/git/bzr é:

• entrar no diretório src
• fazer checkout do trunk
• rodar os comandos de construção (configure, make e make install, por exemplo)
• remover arquivos temporários

Segue um exemplo de PKGBUILD de um pacote svn:

# Contributor: Hugo Doria <hugodoria@gmail.com>
# Use versionpkg to update.

pkgname=billreminder-svn
pkgver=335
pkgrel=1
pkgdesc=”Small and quick accounting application designed to allow for easy tracking of bills”
arch=(’i686′ ‘x86_64′)
url=”http://billreminder.sourceforge.net/”
depends=(’python-pysqlite’ ‘python-notify’ ‘dbus-python’ ’setuptools’ ‘desktop-file-utils’ ‘pygobject’ ‘pygtk’)
makedepends=(’subversion’)
license=(’MIT’)
provides=(’billreminder’)
conflicts=(’billreminder’)
source=()
md5sums=()

_svntrunk=https://billreminder.svn.sourceforge.net/svnroot/billreminder
_svnmod=billreminder

build() {

# Entra no diretório src. A variável $startdir, como o nome diz,
# sempre indica o caminho inicial do pkgbuild.

cd ${startdir}/src

# Checa se existe o $_svnmod/.svn.
# Se existir ele entrar no diretório e faz o update. Se não, ele faz tudo.

if [ -d ${_svnmod}/.svn ]; then
(cd ${_svnmod} && svn up -r ${pkgver})
else
svn co ${_svntrunk} –config-dir ./ -r ${pkgver} ${_svnmod}
fi

# Mensagem para indicar que o checkout terminou e que vai começar o make

msg “SVN checkout done or server timeout”
msg “Starting make…”

# Faz uma cópia do $svnmod e entra nela. A construção é feita de lá.

cp -r ${_svnmod} ${_svnmod}-build
cd ${_svnmod}-build/trunk

# Roda o comando necessário para se instalar o pacote. Aqui poderia ser, por exemplo: ./configure; #make; make install

python setup.py install –root=${startdir}/pkg

# Remove arquivos temporários

rm -rf $startdir/src/${_svnmod}-build

}

DICAS:

1. Para descobrir o número da revisão do svn (que você pode usar na variável pkgver) faça:

source PKGBUILD
svn info $_svntrunk

2. Sempre use versionpkg ao invés de makepkg para construir pacotes svn e cvs. O versionpkg tenta pegar a revisão mais atual automaticamente.

3. PKGBUILDs de pacotes cvs, git e bzr seguem o mesmo principio. Você pode ver exemplos aqui:

http://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines

Referências:

• http://wiki.archlinux.org/index.php/ABS_-_The_Arch_Build_System
• http://wiki.archlinux.org/index.php/PKGBUILD
• http://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines

Segunda-feira eu já tinha recebido a notícia, mas somente agora tudo está oficializado: Eu sou o mais novo desenvolvedor oficial do Arch Linux. Isso significa algumas coisas:

• Meu trabalho no projeto está sendo muito bem reconhecido;
• Tenho muito mais responsabilidades agora;
• Posso manter pacotes dos repositórios principais do Arch;
• Participo das principais decisões;
• Agora ganho em dólar;

uhu!! \O/

Esta notícia me vez relembrar algumas coisas. Quando comecei a usar o Arch eu nem pensava que iria adorar tanto uma distribuição a ponto de trocar meu velho Slackware por ela, e muito menos que viraria um desenvolvedor da própria. Ainda bem que eu estava enganado.

O Arch tem o que sempre procurei em uma distribuição: poder, estabilidade, velocidade, os softwares mais recentes e, principalmente, uma comunidade super aberta a contribuições (que foi o principal motivo para eu largar o Slack).

Graças a esta abertura da comunidade eu pude contribuir com mais coisas e mais rapidamente. Traduzi, documentei, reportei e ajudei a corrigi bugs, empacotei etc. No final do ano passado eu consegui virar um Trusted User - o reponsável por manter pacotes do [community] e o AUR em ordem -  e nesta semana eu me tornei um desenvolvedor oficial do projeto.

Felizmente eu não fui o único com sangue brasileiro a conseguir isso. O Douglas Soares também está virando um desenvolvedor junto comigo. O cara faz um #$#$ trabalho, foi o criador do Arch Linux Brasil e quem me ajudou a virar um Trusted User. É um prazer e orgulho estar nessa junto com ele.

Tenho algumas idéias em mente para o projeto e devo ter novidades em breve. Antes, porém, preciso me habituar com o novo sistema e testar algumas coisas.

Bem, é isso. Agora vou abrir uma gelada, descansar e durmir com um sorriso estampado na cara. :P

Navegando encontrei um artigo muito interessante escrito por Stephen Kanitz, um administrador graduado em Harvard, na qual ele fala sobre a forma que são feitas as avaliações em instituições de ensino, artigo interessante que faz você refletir tanto para aqueles que ensinam ou são alunos. vale a pena da uma lida e refletir sobre essas ideias bastante inovadoras, abaixo segue um trecho.

“Imaginem um sistema geral de
auto-avaliação em que os alunos
não mais estudariam para as provas,
mas estudariam para ser úteis na vida”

Link do artigo aqui.

…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se você puder doar diretamente, ou contribuir de outra forma, são sempre melhores opções. Mas se não puder, veja as regras da promoção e participe - quanto mais divulgação, maior será a doação do BR-Linux e do Efetividade, e você ainda concorre a diversos brindes!

Sou leitor regular de ambos sites, e não podia deixar de participar! Eu queria mesmo era ter comprado o Asus EEE PC 900, mas ele não apareceu no mercado brasileiro, então um Asus EEE PC 701 estaria ótimo! Mas vai ser difícil ganhar alguma coisa, já que pelo visto muita gente resolveu participar!

Compartilhe!

Ajude a sustentar a Wikipédia e outros projetos, sem colocar a mão no bolso, e concorra a um Eee PC!…e também a pen drives, card drives, camisetas geeks, livros e mais! O BR-Linux e o Efetividade lançaram uma campanha para ajudar a Wikimedia Foundation e outros mantenedores de projetos que usamos no dia-a-dia on-line. Se [...]

Just booked my flights to Istambul. I’ll stay at the Golden Horn Hotel (Sirkeci). I’m sure I’ll have an amazing time at GUADEC. Yay!

O feed do meu blog esteve com defeito desde que atualizei para o WordPress 2.5, situação essa que só foi resolvida com a versão 2.5.3 do Gengo, o plugin que estava com defeito. Agradeço aos desenvolvedores e usuários do Gengo pela agilidade com que resolveram o problema! Se você acompanha meus artigos através do Planeta GNU/Linux Brasil, do Planeta GNOME Brasil ou do Planeta Gentoo, deve ter perdido três artigos que escrevi recentemente: um com notícias sobre o acordo ortográfico, outro com cinco quadrinhos recomendados, e outro divulgando a marca dos dez mil spams recebidos. Confira!

Compartilhe!

Infelizmente o jogo de hoje entre Brasil e Argentina não foi televisionado aqui nos Estados Unidos (pelo menos não onde moro). Eis que meu pai me liga de NY para me dizer que viu um dono de bar plugando a sua televisão à internet para assistir a pelada. Rapidamente anotei o site: http://www.justin.tv A imagem não [...]

Andar pela cidade de São Paulo sem reparar na variedade de rostos e culturas presentes é uma tarefa praticamente impossível. Dado o enorme número de imigrantes, que vão desde Portugal até o Japão, é interessante pegar um metrô e reparar como cada pedaço do mundo consegue estar dentro de um simples trem.

Uma das culturas mais presentes no cenário paulistano é a cultura japonesa. No bairro da liberdade, pertinho do centro, é possível ouvir pessoas falando no seu idioma nativo. Muitas fachadas têm seu nome escrito em Katakaná e em português, e além dos muitos restaurantes há Yakisoba sendo vendidos em barracas. Andar por lá é muito divertido. Além de outros bairros com uma grande influência nipônica como a Vila Sônia que fica aqui do lado de casa e cujas ruas sempre são povadas por ikkeys, nisseis, sanseis e yanseis.

Hoje, com a barriga cheia de sushis (por uma incrível coincidência fui comer sushis hoje), escrevo em agradecimento a este povo, que se mostra tão presente, pelo menos na minha vida. Meus pais trabalharam um bom tempo na Sharp, que é uma empresa japonesa. Assisti na minha infância muitas coisas vindas do japão como Jaspion, Changeman, Jiraya e Cavaleiros do Zodíaco. Gosto muito de ler alguns mangás, como Buda, de Osamu Tezuka e sou um grande fã de culinária japonesa. Além do que sempre joguei muitos jogos da Nintendo que é japonesa também.

Parábens, comunidade de descendentes de japoneses que vivem no Brasil a um século.

Olá, pessoal.

Algumas novidades do Vinagre desde a versão 0.5 (GNOME 2.22):

• Suporte inicial ao redimensionamento de tela, baseado em OpenGL
• Painel lateral mostra os marcadores e máquinas descobertas pelo avahi
• Nova opção de linha de comando para fins de tratamento de erros: –gtk-vnc-debug
• Modo somente-leitura
• Opção para envio de CTRL-ALT-DEL
• Única instância do aplicativo rodando. Nova opção de linha de comando (–new-window) para abrir uma nova janela
• Não mostra abas se só existe uma conexão ativa
• Suporte a sintaxe máquina::porta na linha de comando
• A janela de nova conexão agora lembra as máquinas/portas digitadas anteriormente
• Nova barra de ferramentas na tela cheia. Ela aparece automaticamente quando você move o mouse para o topo da tela
• Applet para o painel do GNOME. Acesso rápido aos marcadores e às máquinas descobertas pelo avahi.
• Melhor compatibilidade com servidores VNC

A versão atual do Vinagre é a 2.23.4, e pode ser encontrada nos servidores FTP do GNOME.

Em outras notícias, estou pronto para o GUADEC (ou quase pronto, ainda falta escrever minha apresentação). Muito ancioso pra conhecer toda a galera do GNOME!

Próxima sexta tô indo pra São Paulo, passar somente o fim de semana, curtir uns dias frios! Graças a GOL, que vendeu passagens de Maceió pra lá por R$9,00!! Inacreditável!

Ok, now that I’ve already made my point about our great achievements, it’s time to talk about the big questions. I ended up writing too much, sorry :-P I won’t discuss about solutions or practical actions in this post because (obviously, I don’t have all the answers and) I prefer to separately talk about solutions and practical actions in another post. I’ll try to bring the topics that have been looping in my head (for a quite long time already) with regards to our beloved project. They overlap in many ways with the opinion of some people who have already commented on the “decadence“.

One the most important steps on the process of finding a good solution for a problem is to define the problem. People have different expectations and perspectives about GNOME and hence they define the “decadence” and, consequently, the possible solutions, in different ways. First of all, a more fundamental question: do we have a problem? We already have a great desktop environment for the current standards and demands. So, what is “wrong” here? From what I can see, the problem can be defined in terms of three aspects: Audience, Position and Process. All those have something to do with the fact that GNOME is getting “out of sync” with… something. I fully agree with Rodney, Havoc, Mikkel and others here: the whole desktop concept itself is some sort of dead-end (even though we could be innovating much more in this area) and is, in a certain way, getting outdated (considering the new ways people have been using technology nowadays). Because of that, I think it’s quite dangerous to exclusively stick with the “desktop” goal because we may be missing a lot of opportunities (and even get into an actual decadence situation) in the near future if we keep doing the same things in the exact same way. (One might argue that we already have GNOME Mobile and all. However, I’d say that this is not enough because 1) the mobile front has been done in a kind of “marginal” way inside the project 2) “mobile” is just one among many possible paths). So, yes, we do need to open GNOME for a whole new range of possibilities in a consistent way but first we need to create the right environment for innovation.

Anyway, let me talk about each part of this problem. Those might sound a little abstract sometimes but, in my opinion,  they summarize the big questions we need to answer now.

Audience is about who we’re targetting and, consequently, the fundamental definition and goals of GNOME. I’ve just said that we already have a great desktop. However, we can see quite often people complaining about the lack of innovation, the need for new apps and more eye-candy, and so on. Consequently, we have quite often those endless discussions about the future of GNOME and where we should be heading towards: 3D desktop? Online desktop? Corporate desktop? Topaz? The thing is: everyone is right in a way. Why? Because we don’t have a clearly-defined audience (something that Havoc said 3 years ago).

When I look at what we’ve done so far, I would say we got to develop a simple, intuitive, functional desktop environment that works pretty well on the corporate world and good enough for home users. From my perspective, in terms of user experience, we’re somewhere between MS Windows and MacOS: we’re not as boring as MS Windows (that works relatively well as a productivity/corporate type experience) and not as stylish as MacOS (that aims to provide a more nichey media/life experience on computers). Also, we’re not clearly the best of breed on any of those areas: corporate, life, media, or any other experiences (Don’t get me wrong here: I think we do an amazing work in general. I just consider that we don’t provide an extremely appealing experience on any of those areas *yet*). I’m talking about desktop user experiences here but we can’t ignore the big changes in the personal computing field through the countless types of mobile devices, smart appliances, online apps and services, etc, that demand more and more the hability to customize, adapt and extend existing open source/free technologies in order to deliver competitive and exciting products. With that said, some fundamental questions arise:

1. Is it doable to stick only with development a desktop environment in GNOME?
2. Which kind of desktop do we aim to develop? A corporate type? A media experience type? Something else? Do we really have to choose?
3. Are we responding properly to the demand for the creation of custom user experiences (for distros, mobile devices, online services, etc) with a consistent, productive and powerful software platform?

About 1 and 3, yes, we have GNOME Mobile - which aims to provide a standard architecture and platform that can be used by companies to develop GNOME-based mobile devices. But how strongly does GNOME Mobile define GNOME as a whole? There are some good lessons we can take from GNOME Mobile in terms of development process and organization (more on that in the next post). It’s pretty clear that the strongest point of connection between GNOME Mobile and GNOME is our platform. However, GNOME Mobile is not working as integrated as it should inside GNOME because we still define us as a “desktop project”. So, my short answers to those questions are:

1. No, we should expand the definition and goals of GNOME to embrace the diversity of ways people are (and will be) using technology today (and in the near future).
2. I don’t think we need to choose. What we need is to clearly define and maybe separate different products around different GNOME audiences.
3. No, I think we’re not properly organized to provide a powerful platform for different user experiences because, as I said, we still define ourselves as a “desktop project”. In my opinion, the platform should be the core of GNOME and GNOME Mobile should be closer and share more inside the major activities of the project.

The Audience issues presented above have a tight connection with the relationship between GNOME and distributors. That takes me to the Position issues.

Position is about where we place GNOME in the innovation ecosystem. So far, the relationship between GNOME and distributors is so that we release our official modules (organized inside the desktop, platform, admin, devtools and bindings suites) and distributors adapt and package those modules to integrate in their systems. Normally, they also add a bunch of modules that were (fully or partially) developed with GNOME platform but are not officially part of GNOME suites. Then, when everything is integrated and stable, distributors release their products with GNOME. This model has two interesting aspects.

The first one is: GNOME is invisible to users. From end-users perspective, they are using Ubuntu, Fedora, openSUSE, Foresight, Debian, Gentoo, (add-your-favorite-distro-here) on their personal computers, not GNOME. (Note that I’m not talking about geeky users but about real end-users who don’t know much about technology). This is (and will be) even stronger on consumer products using GNOME platform such as internet tablets, cell phones, PDAs, etc. To verify that, just pretend you’re just an end-user and have a look at the websites of most of desktop distros: they talk about desktop but rarely mention GNOME. (Note that I’m not making any judgements about this here. I’m trying to just bring the fact to the table).

The second aspect is that distributors redefine the user experience. Most of distributors change in some way the default GNOME desktop to fit and integrate nicely with their products. openSUSE has a completely different panel layout and use gnome-main-menu. Most of distros use Firefox instead of Epiphany. Latest releases of the major desktop distros ship with Compiz by default instead of Metacity. Also, they integrate desktop modules that are not directly provided by GNOME: Pidgin for instant messaging, Rhythmbox or Banshee for music management, F-Spot or GThumb for photo management,  Beagle or Tracker for desktop search, and the long list continues.

So, based on those aspects, what can we say? First: even with our current development process where we release suites of official modules to distributors, it’s not clear inside GNOME whether we are “user experience definers” or “component providers for custom user experiences”. Currently, we’re defining most of the desktop user experience through our official modules. However, because of the way we define our final product (the suites of official modules) there are certain areas where we simply don’t reach an agreement (more on that later). Why haven’t we ever chosen a “official” music player? Why no photo management app in the desktop? Gimmie or gnome-main-menu or just keep the menu bar? Why is there so much discussion around the inclusion of Empathy? The fact is, for some reason, there are certain topics around the user experience that we just prefer to not decide about. This makes us stay in a unclear position: we kind of define the experience - but only on certain topics (this has a lot to do with the lack of a defined audience and our development process). That brings me the following questions:

1. Should GNOME be a “user experience definer” or “component provider”? Do we need to choose?
2. Does the GNOME decisions about the official modules really matter? If so, at what level?

My answers to those questions are:

1. We should be component providers - but in a special way. In my opinion, we should platformize the user experience in a way that our modules can be easily reused in different contexts or products. In practice, this means: providing highly configurable and pluggable core components; well-defined services D-Bus APIs so that we easily replace compliant implementations with same interface; refreshed toolkit which embeds sexy UI elements and interactions; and more. In order to properly be component providers, we would need to provide a super-powerful platform though. Yes, that would be a big challenge (more on that in the next post).
2. Yes, our module decisions matter. But they only *really* matter if they are related either to platform or to the “core” desktop components (panel, session, nautilus, keyring, settings daemon, capplets, etc).

So, in reality, the ecosystem around GNOME is demanding a lot of flexibility in the platform and desktop - specially from stakeholders producing mobile devices and other custom user experiences based on GNOME. We need to clarify our position and goals inside this ecosystem so that we can embrace all the great possibilities we have inside our community. We should redefine GNOME as a platform for intuitive and exciting user experience with several reference products for different audiences around it. In order to redefine the project, we need to rethink the way we do things. Let’s talk about the Process problem.

Process is about how we do things. As I said in my last post, the same process that brings so many benefits is the one that’s making GNOME stall somehow. Why? Because our current process is organized around the fact that we’re in deep maintenance mode. Actually, in a way, we’ve been in maintainance mode since the 2.0 release. The main problem with this mode is that all decisions in GNOME are done based the tacit assumption that we should never break anything (as if the maintenance mode is a given). This brings a very good feeling that everything is stable and predictable most the time. And that’s very true actually. However, having stability (in sense of “no big changes so everything works, cool”) for a too long period is boooooring and brings all the problems of Audience and Position (because with technology, everything gets outdated very quickly). Let me talk about some aspects of this maintenance mode in GNOME

The first one is that we don’t have a “big picture” to base our decisions on 2.x. Yes, we are basically “adding or replacing stuff” in the same good old stack for quite some time already. The problem here is: the big picture of 2.x is kind of “done”, “given”. We’re basically in passive mode, just waiting for contributors to decide to propose and include random modules in one of our suites. Some people may argue that we’re constantly improving the platform and desktop by revamping certain components every now and then and that shows we’re moving the project forward. In my opinion, this is not entirely true. Yes, we’ve been doing some nice improvements in 2.x but the requirement to never break anything (associated with the Audience and Position problems) almost completely blocks innovation inside GNOME and very often moves the cool innovation work to distributors side (because they can break and change anything as they want anyway). And, unfortunately, many times we end up not being able to accept distros’ innovation work because we can’t break anything. Note that I’m not saying that stability is bad. My point here is that we should have official long-term break points in GNOME. That would be an enforcement for the community to rethink the big picture from time to time (and not wait for some magic “vision” to change the direction of the project).

The second aspect is the decision making problem. In our current organization of the development process, no one has the official role of deciding about the general direction of the project. Some people say we have a problem of leadership in GNOME. This is partially true. We have the core contributors who are the ones who define the project’s direction in practice. So, we have leaders. However, this leadership is quite fragmented and doesn’t have any official position in our development process. Therefore, the real problem is in the process: the release team is responsible for maintaining the correctness and coherence of the development but not for defining the content. There’s no one in charge of getting the big picture and proposing a development agenda. We need to accept the fact that we need domain/suite maintainers who are responsible for proposing and having the last word about the content and roadmap for certain domains/suites. The recent Roadmap process was a nice achievement on spreading the word (inside and outside our community) about what we’re doing. Not enough to drive the project to a new direction because we’re in maintainance mode after all.

Lastly, the maintenance mode involves a specific definition of our suites and hence the way we deal with third-party applications. The current definition of our suites is too closed and not so flexible. There’s a large amount of apps being developed based on our platform that are simply ignored by us. Of course, there’s is a lot of crappy stuff our there but, on the other hand, there’s a good number of high-quality GNOME-based horizontal and vertical apps (photo managers, media managers, recipes managers, book collection managers, stock managers, web widgets, sexy panel replacements, etc) that we don’t keep close to us in any way. Because of that, we miss the opportunity to get more contributors and all the potential sinergy that those apps could bring to GNOME and our distributors. We need to provide a more clear and interesting place for high-quality third-party apps in GNOME. Those apps are an important part of our innovation ecosystem.

So, from my perspective, considering those three aspects of the problem (Audience, Position and Process), a good solution for it should involve:

1. Expading the definition and goals of GNOME in order to embrace the diversity around us;
2. Defining clear audiences for our products;
3. Redefining the position of GNOME inside our ecosystem so that we bring innovation inside through a powerful platform;
4. Rethinking the development process so that we can: a) have an efficient decision-making chain b) “think from scratch” and break things from time to time c) bring third-party development closer to us.

Also, it’s pretty clear to me (and I know other people agree with me) that GNOME 3.0 should not be just “a next generation desktop” but a new way of defining, organizing and developing GNOME. I’m pretty confident that if we do it properly, innovation will naturally take place. Yes, I know that there are big challenges involved here in terms of resources and community consensus. But those are part of any big change. One of the goals of this post is also to try to propose a (kind of) well-defined set of topics for this “decadence” discussion.

I know that dealing with all questions brought here involves a huge amount of work. However, if we manage to respond in practice at least to a good part of those, I would be extremely happy. :-) Therefore, it’s quite important that we take the opportunity brought by this discussion to draw some concrete proposals for GNOME 3.0. In my opinion, the Release Team has an important role on the coordination of the discussions about the needed process changes and the GNOME Foundation Board should support the community by sponsoring hackfests, bringing advisory board members to actively participate on this discussion, and much more. Coincidentaly, I’m part of both (yay!) and I’ll do my best (together with my fellow release team and board members and the community in general) to make this happen. Honestly, I don’t know yet when I’m gonna write the next post about possible solutions and practical actions because, just like my evil twin, I’m still “still working with some great people on expressing our opinion in a understandable way”. I’m sure GUADEC will be a great opportunity to boost this discussion.

If you read all this, you’re my hero! Thanks! :-)

Sejam muito bem vindos Pretto e Cropalato!

Estes dois heróis do Ubuntu Brasil tiveram seus esforços reconhecidos e são agora membros oficiais Ubuntu.

Meus parabéns, e vamos que vamos!

Assim como o Jonh, informo com grande satisfação que a minha proposta também foi aprovada pela organização do GUADEC. Na verdade a proposta não é só minha, mas em conjunto com três grandes feras: Andre Klapper, Pedro Villavicencio e Tobias Mueller

Nós faremos um encontro do Bugsquad no qual todos os interessados podem participar, desde os que não sabem nada aos veteranos na triagem de bugs.

Mais ou menos copiado do blog de Jonh:

GUADEC - GNOME Users and Developers European Conference - é o maior evento GNOME do mundo, acontece anualmente em alguma cidade da Europa, e reúne a maior quantidade possível de desenvolvedores e usuários. Este ano será em Istambul, Turquia, de 7 a 12 de julho.

Woohoo!!!

Fantástica a iniciativa do Sérgio Amadeu , da Faculdade Casper Líbero, de divulgar na rede um encontro com um dos pioneiros da Internet no Brasil, Demi Getschko. A conversa passou por uma série de temas: a construção da rede no Brasil, as tentativas da indústria de intermediação de impor a lógica hierárquica, os caminhos da privacidade e da segurança, o poder dos fluxos de informação diante dos governos autoritários, as tendências atuais e o futuro da Internet, entre outros.

Além do Demi Getschko, participaram da entrevista o Coordenador de Cultura Geral da Cásper Líbero, Prof. Claudio Arantes, o filósofo e professor da Universidade Complutense de Madri, Javier Bustamante, o pesquisador do CIP, Murilo Machado e o próprio Sérgio Amadeu. Segue então abaixo, os links dos vídeos da entrevista que estão no youtube:

http://br.youtube.com/watch?v=nLjJfhHQ8XI

http://br.youtube.com/watch?v=A4h6O9AkgUQ

http://br.youtube.com/watch?v=1pfrxzyeSCs

http://br.youtube.com/watch?v=AbgEs2VWHl4

http://br.youtube.com/watch?v=RWDVOGStFIo

http://br.youtube.com/watch?v=NWayxnitOlc

http://br.youtube.com/watch?v=Msb1DdvPIH0

http://br.youtube.com/watch?v=Xr9fKaML9k8

Recife receberá o Segundo encontro de Software Livre de Pernambuco nos dias 23, 24 e 25 de abril de 2008, na Faculdade Maurício de Nassau e será gratuito. A organização estima que cerca de 800 pessoas participem do Encontro e ajudem a difundir o Software Livre (SL) nos âmbitos acadêmicos, empresariais, governamentais e sociais.

Dentro deste evento, tive a honra de ter sido convidado pela organização para participar de um painel sobre Software Livre e Economia Solidária , que acontecerá no auditório às 15h de quinta (24/04/08). A minha porposta por lá será de apresentar o projeto do Fórum Brasileiro de Economia Solidária (FBES) que visa o desenvolvimento da comunidade virtual das redes de Economia Solidária (também conhecido como "Sistema FBES") - que a Colivre está desenvolvendo. Como mencionei aqui num post passado, Este ambiente virtual terá como objetivo potencializar e contribuir para o fortalecimento de cadeias produtivas, redes de pro-consumidoras/es e ambientes de comunicação entre os empreendimentos de economia solidária, organizações de assessoria, gestores públicos e cidadãos comuns de todas as regiões do Brasil.

Infelizmente, como estou cheio de compromissos e atividades pela Colivre, chegarei em Recife na quinta às 8h e retornarei para Salvador no mesmo dia às 23h. Por isto, não terei condições por exemplo de assistir duas palestras que gostaria:

• a deJorge Pereira (dia 23/04 - quarta - na sala 02, às 17h) que falará sobre o tema "Contribuindo com o GNOME". Esta apresentação abordará os passos para aqueles que desejam colaborar com o projeto GNOME, seja desenvolvendo, com traduções entre outras formas.

• e a apresentação de Sérgio Amadeu (dia 25/04 - sexta - no auditório, às 15h) sobre "Convergência Digital, Desintermediação e práticas".

Mais informações sobre a programação geral do evento, veja aqui.

Estou escrevendo um jogo chamado gsimon, um clone do velho conhecido Genius para o GNOME. É meu primeiro código usando Cairo e espero que venha seguido por muitos outros.

Pretendo escrever alguns softwares/jogos educativos e propor a adição de um módulo "gnome-edu" no GNOME, que ainda peca muito nessa área.

O que acham da idéia?

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…