05 de April de 2019

Rewarding our Friends of GNOME

After my somewhat dark post about being a Free Software maintainer, a very significant number of people got in touch and asked how can they help me, and GNOME, more actively than saying “keep up the good work, we love y’all”. And so I thought that maybe we are not advertising well enough the various ways to contribute to GNOME beyond actually getting involved with the daily activities of the project.

The potentially most effective way to help GNOME is by donating to the GNOME Foundation and spreading the word. GNOME Foundation has two donation programs: one-time donations, and Friend of GNOME.

Becoming a Friend of GNOME is my favorite. The Friends of GNOME donation program is a monthly subscription where you can select a community member. The selected member will send you a thank you post card. Did you know that I can be adopted as a hacker through Friends of GNOME? Not only me but various other great community members!

I’m happy to say that many Friends of GNOME adopted me already! Naturally, I’m supposed to send thank you postcards.

But I won’t.

I think our Friends should be properly rewarded for helping Free Software.

Local Touch

Brazil has a rich and dynamic culture, with lots of influences from Portugal, Spain, Italy, various african “countries” (thinking of Africa in terms of countries is somewhat wrong; countries were defined by europeans, and do not represent the cultural diversity of Africa) and Asia. And I love that we have wide range of artistic and cultural production that covers this diversity.

It happens that I have a long-time contact with the Okinawan community in Brazil, and know a local Brazilian/Okinawan artist that can create fantastic pieces blending those different cultures. You can check her work at @jay_ceramicas on Instagram (and you should, her work is absolutely fantastic). If you appreciate art, and her art in special, consider requesting her artwork!

I asked her to create different pieces for our Friends of GNOME.

Assembling

The process started with defining the topic of the art that will be produced.

We agreed on representing simultaneously the Brazilian and the Okinawan culture, with the elements that intersect both. Our Friends deserve unique and handcrafted pieces, and that’s what we did.

After she finishing crafting those pieces, I started assembling the gift boxes. It all starts with finding a good box, and gathering the materials:

Next step is preparing the box. First, the essentials: it should feel GNOME, smell GNOME.

Since the box may travel across oceans, let’s ensure the safety of the arts.

Starting to look good!

But that’s not enough. Our Friends chose GNOME to help, so I think it’s safe to assume they would like to show they’re GNOME users. Or at least GNOME supporters. So good set of stickers is a great addition!

The gift box is looking even better now!

Having stickers is excellent, but I don’t want them to turn into a mess when our Friends receive their boxes.

At this point, the boxes look pretty much ready.

But they aren’t! It’s so important to express gratitude. I’m grateful for our Friends to have adopted me, and I want to tell them that.

And now we have something deliverable!


If you are a Friend of GNOME, and adopted me, check your mail box; you might find a surprise… I may have done more than what I wrote here 🙂

And that way, I feel like I’m properly rewarding those who take the next step and, even without the time or the knowledge or the energy to be involved with GNOME, still contribute to the future of the project and of Free Software.

Thanks for supporting Free Software and GNOME.

You are gold.

15 de March de 2019

GNOME 3.32 and other ramblings

GNOME 3.32 was released this week. For all intents and purposes, it is a fantastic release, and I am already using the packages provided by Arch Linux’s gnome-unstable repository. Congratulations for everyone involved (including the Arch team for the super quick packaging!)

I have a few highlights, comments and thoughts I would like to share about this release, and since I own this blog, well, let me do it publicly! 🙂

Fast, Furiously Fast

The most promoted improvement in this release is the improved performance. Having worked or reviewed some these improvements myself, I found it a bit weird that some people were reporting enormous changes on performance. Of course, you should notice that GNOME Shell is smoother, and applications as well (when the compositor reliably sends frame ticks to applications, they also draw on time, and feel smoother as well.)

But people were telling me that these changes were game changing.

There is a grey line between the actual improvements, and people just happy and overly excited about it. And I thought the latter was the case.

But then I installed the non-debug packages from Arch repositories and this is actually a game changer release. I probably got used to using Mutter and GNOME Shell manually compiled with all the debug and development junk, and didn’t really notice how better it became.

Better GNOME Music

Sweet, sweet GNOME Music

One of the applications that I enjoy the most in the GNOME core apps ecosytem is GNOME Music. In the past, I have worked on landing various performance improvements on it. Unfortunately, my contributions ceased last year, but I have been following the development of this pretty little app closely

A lot of effort was put into modernizing GNOME Music, and it is absolutely paying off. It is more stable, better, and I believe it has reached the point where adding new features won’t drive contributors insane.

GNOME Web – a gem

In the past, I have tried making Web my main browser. Unfortunately, that did not work out very well, due to 2 big reasons:

  • WordPress would not work, and as such, I couldn’t write blog posts using Web;
  • Google Drive (and a few other Google websites) would be subtly broken.

Both issues seem to be fixed now! In fact, as you can see from the previous screenshot, I am writing this post from Web. Which makes me super happy.

Even though I cannot use it 100% of the time (mainly due to online banking and Google Meets), I will experiment making it my main browser for a few weeks and see how it goes.

GNOME Terminal + Headebars = 💖

Do I even need to say something?

Hackfests

As I write this, I am getting ready for next week’s Parental Controls & Metered Data Hackfest in London. We will discuss and try to land in GNOME some downstream features available at Endless OS.

I’m also mentally preparing for the Content Apps Hackfest. And GUADEC. It is somewhat hard once you realize you have travel anxiety, and every week before traveling is a psychological war.

Other Thoughts

This was a peculiar release to me.

This is actually the first release where I spent serious time on Mutter and GNOME Shell. As I said in the past, it’s a new passion of mine. Both are complex projects that encompasses many aspects of the user experience, and cleaning the code and improving it has been fantastic so far. As such, it was and still is a challenge to split my time in such a fragmented way (it’s not like I don’t maintain GNOME Settings, GNOME Calendar, and GNOME To Do already.)

Besides that, I am close to finishing moving to a new home! This is an ongoing process, slow and steady, it is becoming something I am growing to love and feel like home.

05 de March de 2019

User account fallback images in GNOME 3.32

Your face might resemble this one in the left (avatar-default) as much as it could be pretty much everyone else using the same computer as you. With this in mind, we introduced a small feature in GNOME 3.32 that intends to make it easier for users to identify themselves in a list of system users, such as in the login screen or in Settings.

From now on, GNOME won’t set the “avatar-default” icon for users created in the Initial Setup or in Setting. It will create a colourful image with the user’s initials on it.

The colour palette is the same used in the new icon guidelines (if you haven’t heard yet, we are living now a Big App Icon Revolution in GNOME!). User names (full names) are mapped to colours in the palette, and therefore are consistent everywhere you enter the exact full user name. So get used to your colour!

Nothing else about the user image setup is going to change. You still can:

  1. Select a picture with a file chooser.
  2. Take a picture with your webcam.
  3. Select one of the GNOME stock avatars.

Another detail that came with these changes is that now user images will be rounded everywhere in GNOME. These efforts are part of the “Consistent user images across GNOME” initiative.

User Accounts panel in Settings
GNOME Initial Setup
Login screen

GNOME 3.32.0 is coming out next week! o/

19 de February de 2019

DevConf.CZ 2019

Last month I attended DevConf CZ for the third time. The conference has been growing a lot in the last years and it has been attracting a wider variety of people. It is a free-admission conference in the lovely Brno, Czech Republic, the place that I now call home. If you haven’t attended it yet, you should definitely consider it for next year.

This year I had a talk titled “Running virtual machines in the Flatpak sandbox”, where I described the process of Flatpaking GNOME Boxes. There’s a video available on YouTube.

We had a small Desktop track on Friday afternoon with a good amount of talks about Flatpak. The audience was engaged and interested in the topics. Besides of my talk, Owen Taylor spoke about the state of Flatpaks in Fedora and Jiří Janoušek spoke about the Linux fragmentation and how Flatpak can tackle the problem. Last but not least, Kalev Lamber told us what’s new in gnome-software.

15 de November de 2018

Istio: O que acontece quando o painel de controle está inativo?

Olá, pessoal!

Eu fiz alguns experimentos no Istio derrubando alguns componentes do painel de controle e observando o que acontece com os aplicativos e a mesh de serviço. Abaixo você encontrará minhas anotações.

Pilot

O Pilot é responsável pelo recurso de gerenciamento de tráfego do Istio e também é responsável por atualizar todos os sidecars com a configuração de mesh mais recente.

Quando o Pilot inicia, ele escuta na porta 15010 (gRPC) e 8080 (HTTP legado).

Quando o sidecar do aplicativo (Envoy, Istio-Proxy) é iniciado, ele se conecta ao pilot.istio-system:15010, obtém a configuração inicial e mantém-se conectado.
Sempre que o pilot detecta uma alteração na mesh (ele monitora os recursos do kubernetes), ele envia uma nova configuração para o sidecars por meio dessa conexão gRPC.

– Se o pilot cair, essa conexão do gRPC entre o piloto e o sidecar será perdida e os sidecars tentarão se reconectar ao pilot indefinidamente.
– O tráfego não é afetado se o pilot estiver fora do ar, porque toda a configuração enviada para o sidecar reside na memória do sidecar.
– Mudanças na mesh (como novos pods, regras, serviços, etc) não chegam aos sidecars, porque o pilot não está lá para ouvir mudanças e encaminhá-las para o sidecars.
– Uma vez que o pilot está ativo novamente, os sidecars se conectam (porque estão sempre tentando se reconectar) a ele e pegam a configuração de mash mais recente.

Mixer Policy

Policy aplica a política de rede.

Mixer lê a configuração na inicialização e também monitora kubernetes para alterações. Uma vez que novas configurações são detectadas, o mixer as carrega em sua memória.

Os sidecars verificam (chamam) o pod mixer policy para cada solicitação direcionada a aplicação (serviço).

Se o pod mixer policy estiver inativo, todas as solicitações para o serviço falharão com um erro “503 UNAVAILABLE: no healthy upstream” – porque o sidecar não pôde se conectar ao pod policy.

No Istio 1.1, há uma nova configuração (policyCheckFailOpen) [global] que permite uma política “Fail Open”, isto é, se o pod mixer policy não estiver alcançável, todas as requisições terão sucesso em vez de falhar com um erro 503. Por padrão, essa configuração está definida com false, isto é, “Fail Close”.

Enquanto o mixer estiver inativo, tudo o que fazemos na mesh (como adicionar regras, alterar qualquer configuração, etc) não terá efeito nos aplicativos até que o mixer esteja ativo novamente.

Mixer Telemetry

Telemetry fornece informações de telemetria para os addons.

Os Sidecars chamam o pod Telemetry após cada solicitação ser concluída, fornecendo informações de telemetria aos adaptadores (Prometheus, etc). Ele faz isso em lotes de 100 solicitações ou 1 segundo (na configuração padrão), o que vier primeiro, para evitar chamadas excessivas ao pod Telemetry.

Se o pod Telemetry estiver desativado, os sidecars registram um erro (no stderr do pod) e descartam as informações de telemetria. As solicitações não são afetadas por isso, como acontece quando o pod Policy está inativo. Uma vez que o pod Telemetry está ativo novamente, ele começa a receber informações de telemetria dos sidecars.

Outras notas

Vale a pena observar que o Istio permite uma instalação personalizada de seus componentes de plano de controle. Por exemplo, se você não precisa de Policy, pode desabilitar totalmente o mixer policy. Essa modularidade está melhorando no Istio 1.1. Para mais informações, confira a documentação.

Além disso, o pilot, mixer policy e a mixer telemetry funcionam bem em uma configuração de alta disponibilidade (HA), com várias réplicas sendo executadas ao mesmo tempo. Na verdade, a configuração padrão vem com um HorizontalPodAutoscaler que varia de 1 a 5 para esses pods. (Curioso? Veja isso e isso).

18 de October de 2018

Um Novo Atalho no Evince. O que há por trás disso?

Não sei se você está sabendo, mas a versão nova do Evince (3.30) está com um atalho bastante útil.

Agora você pode destacar uma parte do texto selecionando-a com o mouse e pressionando as teclas:

CTRL + H

Este post poderia parar por aqui, mas eu gostaria de escrever mais um pouco acerca do que está por trás de um simples atalho.

O Evince e Eu

O Evince é um visualizador de documentos do GNOME. De acordo com a Wikipedia ele foi incluído no GNOME em sua versão 2.12.

No meu dia a dia, de grande consumo de informações através de arquivos PDF, um bom leitor é fundamental. O Evince sempre supriu bem este papel, porém havia um ponto que me incomodava: a falta de um atalho para destacar as partes relevantes do texto.

Para fazer isso eu tinha que utilizar o mouse, movimentando o cursor do texto até o botão de destaque, ou fazendo o contrário.

O Atalho

Em conversas informais no canal do IRC do GNOME Brasil1, comentei que sentia falta deste recurso. Na época usava o Evince 3.28.

Durante a conversa, o amigo Felipe Borges feborges pediu um tempinho e, em poucos minutos, disse que tinha implementado tal recurso e que ele viria, possivelmente, na próxima versão do Evince.

Lembro que fiquei num misto de alegria e de espanto pela rapidez do processo e também pela consideração de feborges.

Bem, estou usando a versão 3.30 do Evince e estou usando bastante o recurso. Recomendo 😉

Queria concluir este post agradecendo ao Felipe pelo recurso, mas também deixando uma reflexão sobre como o software livre e open source é produzido e melhorado.

Acompanho, em muitos espaços, usuários reclamando da falta do recurso X ou do bug Y, porém pouca gente abre alguma issue para relatar algum bug ou propor alguma melhoria.

Diversas vezes esse modelo de desenvolvimento de software é enquadrado em uma lógica diferente e sofre análises, muito deslocadas a meu ver, como se fosse um modelo proprietário. Mas isso é um papo para um outro post.


  1. irc.gnome.org #gnome-br 

11 de October de 2018

Fedora 29 Beta

Estou completando duas semanas de uso do Fedora 29 Beta. Até o momento só tive um crash. Por aqui já estamos no GNOME 3.30.1.

No geral a experiência está sendo bastante agradável e estável. Abaixo eu descrevo como fiz para transformar a versão 28 em 29.

Se quiser atualizar o seu sistema, faça por sua conta e risco ok? Lembre-se: faça backup! Desative o rpm-fusion (eu não fiz, mas é aconselhado fazer).

Atualizar o Sistema Atual

sudo dnf upgrade --refresh

Instalar o Plugin para Atualização

sudo dnf install dnf-plugin-system-upgrade

Baixar os Pacotes

sudo dnf system-upgrade download --refresh --releasever=29

Finalizar

sudo dnf system-upgrade reboot

Se tudo der certo…

dnf clean packages

O que você está achando do Fedora 29 ou do GNOME 3.30. Conta aí!

24 de September de 2018

Istio, injeção de sidecar: ativando injeção automática, adicionando exceções e depuração

Ei pessoal. Hoje vamos falar sobre um pouco sobre injeção de sidecar do Istio em Kubernetes.

O Istio no Kubernetes funciona usando um modelo de deployment de sidecar, onde um contêiner auxiliar (sidecar) é anexado ao seu contêiner principal (serviço) em um único Pod. Ao fazer isso, seu serviço e o contêiner de sidecar compartilham a mesma rede e podem ser vistos como dois processos em um único host. Assim, o Istio pode interceptar todas as chamadas de rede de e para o seu contêiner principal e fazer sua mágica para melhorar a comunicação de serviço a serviço.

Esse contêiner de sidecar, denominado istio-proxy, pode ser injetado em seu pod de serviço de duas maneiras: manual e automaticamente. Mesmo essa técnica manual não é 100% feita à mão. Vamos ver.

Injeção manual

O Istio vem com uma ferramenta chamada istioctl. Sim, parece que é inspirado em alguma outra ferramenta amada :). Uma de suas funcionalidades é a capacidade de injetar o sidecar istio-proxy em seu pod de serviço. Vamos usá-la, usando um simples pod de busybox como exemplo:

$ cat busybox.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: busybox-test
spec:
  containers:
  - name: busybox-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep infinity']

$ istioctl kube-inject -f busybox.yaml > busybox-injected.yaml

[jwendell@jw-laptop ~]$ cat busybox-injected.yaml 
apiVersion: v1
kind: Pod
metadata:
  labels:
  name: busybox-test
spec:
  containers:
  - command:
    - sh
    - -c
    - echo Hello Kubernetes! && sleep infinity
    image: busybox
    name: busybox-container

  - image: docker.io/istio/proxyv2:1.0.2
    imagePullPolicy: IfNotPresent
    name: istio-proxy
    args:
      - proxy
      - sidecar
   ...

Como você pode ver acima, esse comando gerou outro arquivo yaml, semelhante ao input (pod busybox), mas com o sidecar (istio-proxy) adicionado ao pod. Então, de alguma forma, isso não é um trabalho manual de 100%, certo? Isso nos poupa um monte de digitação. Você está pronto para aplicar este yaml modificado ao seu cluster do kubernetes:

$ kubectl apply -f busybox-injected.yaml
# ou, se você não quiser ter um arquivo intermediário, aplique diretamente usando o arquivo original:
$ kubectl apply -f <(istioctl kube-inject -f busybox.yaml)

Uma pergunta natural que pode surgir é: de onde vêm esses dados? Como ele sabe que a imagem do sidecar é docker.io/istio/proxyv2:1.0.2? A resposta é simples: Todos os dados vêm de um ConfigMap que vive no plano de controle do Istio, no namespace istio-system:

$ kubectl -n istio-system describe configmap istio-sidecar-injector
Name:         istio-sidecar-injector
Namespace:    istio-system

Data
====
config:
----
policy: enabled
template: |-
  initContainers:
  - name: istio-init
    image: "docker.io/istio/proxy_init:1.0.2"
...

Você pode editar este ConfigMap com os valores que deseja injetar nos seus pods. Como você pode ver, esse é basicamente um modelo que será adicionado à sua definição de pod. Se você quiser usar outra imagem para o contêiner istio-proxy, use outra tag ou deseje ajustar qualquer coisa que será injetada, essa é a coisa que você precisa editar. Lembre-se que este ConfigMap é usado para injeção em todos os seus pods na malha de serviço. Seja cuidadoso 🙂

Porque istioctl lê um ConfigMap para saber o que injetar, isso significa que você precisa ter acesso a um cluster do Kubernetes em funcionamento com o Istio devidamente instalado. Se por algum motivo você não tiver tal acesso, você ainda pode usar istioctl, fornecendo um arquivo de configuração local:

# execute isso antes, com acesso apropriado ao cluster k8s
$ kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}' > inject-config.yaml
# sinta-se à vontade para modificar esse arquivo, e você pode executar a qualquer momento depois:
$ istioctl kube-inject --injectConfigFile inject-config.yaml ...

Injeção automática

A outra maneira de ter istio-proxy injetado em seus pods é dizendo ao Istio para fazer isso automaticamente por você. Na verdade, isso é ativado por padrão para todos os namespaces com o rótulo istio-injection=enabled. Isso significa que, se um namespace tiver esse rótulo, todos os pods dentro dele receberão o sidecar istio-proxy automaticamente. Você não precisa executar istioctl ou fazer qualquer coisa com seus arquivos yaml!

O modo como funciona é bem simples: ele faz uso de uma funcionalidade do Kubernetes chamado MutatingWebhook que consiste em Kubernetes notificando o Istio sempre que um novo pod está prestes a ser criado e dando ao Istio a chance de modificar a especificação do pod durante seu uso, pouco antes de realmente criar esse pod. Assim, o Istio injeta o sidecar istio-proxy usando o template encontrado no ConfigMap que vimos acima.

Soa bem, certo?

Você pode estar se perguntando: Ei, isso é muito intrusivo! Sim, tudo depende das suas necessidades. Esta injeção automática é muito flexível:

  • No istio-sidecar-injector ConfigMap, há um sinalizador booleano indicando se esta injeção automática está habilitada ou não.
  • Somente os namespaces rotulados adequadamente receberão a injeção automática. Você pode escolher seletivamente quais namespaces terão injeção automática.
  • Além disso, você pode ajustar esse rótulo, alterá-lo ou mesmo remover esse filtro (o que significa que a injeção ocorrerá automaticamente em todos os namespaces! Seja cuidadoso!) Editando o MutatingWebhookConfiguration: kubectl -n istio-system edit MutatingWebhookConfiguration istio-sidecar-injector. Procure o campo namespaceSelector.
  • Você pode evitar que a injeção aconteça em pods seletivos. Se um pod tiver a anotação sidecar.istio.io/inject: "false", então o Istio não irá injetar o sidecar nele.
  • Você pode inverter a lógica se você for mais conservador. Desative a injeção automática para todos e ative-a apenas para pods selecionados. Para isso, você só precisa definir a política como falsa (kubectl -n istio-system edit configmap istio-sidecar-injector) e anotar os pods que você deseja para injetar com sidecar.istio.io/inject: "true"

Eu quero mais flexibilidade!

Aqui está um caso de uso em que a flexibilidade acima não foi suficiente:

Para aqueles que não estão familiarizados com o Openshift (distribuição de Kubernetes da Red Hat), ele possui uma funcionalidade chamada source-to-image – s2i, que magicamente cria imagens de contêiner com base no código-fonte. Você fornece um repositório git (funciona com muitas linguagens de programação!) como entrada e obtém uma imagem de contêiner, sendo executada no Openshift como resultado.

É uma funcionilidade incrível! Não vou entrar em detalhes aqui, vou apenas dizer o que precisamos saber agora: para fazer isso, o Openshift cria um ou mais pods auxiliares, intermediários, para construir o código-fonte. Quando a compilação estiver concluída, os artefatos binários vão para a imagem do contêiner resultante, prontos para serem executados no Openshift, e esses conjuntos auxiliares são então descartados.

Se habilitarmos a injeção automática em um determinado namespace e usarmos a funcionalidade de s2i do Openshift, isso significa que todos os pods receberão o sidecar injetado. Mesmo aqueles pods compiladores (intermediários, auxiliares)! Pior, como eles não estão sob nosso controle (eles são criados pelo Openshift, não por nós), não podemos anotar para não obter o sidecar injetado. As compilações não se comportam bem com o sidecar injetado, então não queremos que eles sejam automaticamente injetados. O que fazer agora?

Bem, uma solução possível é seguir a abordagem conservadora explicada no último item acima: Desativar a injeção automática para todos e ativá-la apenas para os pods selecionados. Isso funciona, mas exige que você anote ativamente os pods que você deseja que a injeção automática aconteça.

Ou… Há uma nova solução para esse problema:

A nova solução

A partir da versão 1.1.0, a injeção automática do Istio tem uma maneira de adicionar exceções com base em rótulos, ou seja: não injetar o sidecar em pods que correspondam a esses rótulos, mesmo se a política for true e esse namespace for marcado para ter injeção automática. Você pode adicionar essas exceções no istio-sidecar-injector ConfigMap:

$ kubectl -n istio-system describe configmap istio-sidecar-injector
apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-sidecar-injector
data:
  config: |-
    policy: enabled
    neverInjectSelector:
      - matchExpressions:
        - {key: openshift.io/build.name, operator: Exists}
      - matchExpressions:
        - {key: openshift.io/deployer-pod-for.name, operator: Exists}
    template: |-
      initContainers:
...

Você pode ver acima um campo neverInjectSelector. É uma matriz de seletores de rótulos de Kubernetes. Eles são comparados com OR, parando no primeiro jogo. A instrução acima significa: Nunca injetar em pods que tenham o rótulo openshift.io/build.name ou openshift.io/deployer-pod-for.name – os valores dos rótulos não importam, estamos apenas verificando se as chaves existem. Com essa regra adicionada, nosso caso de uso de s2i do Openshift está coberto, o que significa que os pods auxiliares não terão sidecars injetados (porque os pods auxiliares de s2i contêm esses rótulos).

Para completar, você também pode usar um campo chamado alwaysInjectSelector, que sempre injetará o sidecar em pods que correspondam ao seletor de rótulo, apesar da política global.

A abordagem do seletor de rótulos oferece muita flexibilidade sobre como expressar essas exceções. Dê uma olhada em sua documentação para ver o que você pode fazer com eles!

Vale a pena observar que as anotações nos pods ainda têm a preferência. Se um pod é anotado com sidecar.istio.io/inject: "true/false", então ele será honrado. Então, a ordem de avaliação é:

Pod Annotations → NeverInjectSelector → AlwaysInjectSelector → Namespace Policy

Como este {Never,Always}InjectSelector é uma adição recente, eu ainda tenho que atualizar as documentações para mencioná-lo, mas para todas as outras coisas, para mais informações e exemplos confira a documentação oficial.

Por que meu pod [não] está sendo intejado?

Essa é uma pergunta muito comum. Você seguiu todas as instruções (como rotular o namespace com istio-injection=enabled) e seus pods não estão recebendo a injeção automática.

Ou bem pelo contrário, você anotou seu pod com sidecar.istio.io/inject: "false" e ele está sendo injetado. Por que?

Uma coisa que você pode fazer para descobrir o que está acontecendo é olhar nos logs do pod sidecar-injector:

$ pod=$(kubectl -n istio-system get pods -l istio=sidecar-injector -o jsonpath='{.items[0].metadata.name}')
$ kubectl -n istio-system logs -f $pod

Em seguida, você pode criar seus pods e monitorar aquele log por qualquer saída. Para uma saída de log mais detalhada – confie em mim, é realmente útil – devemos editar o deployment do sidecar-injector e anexar o argumento --log_output_level=default:debug ao executável de contêiner sidecar-injector:

$ kubectl -n istio-system edit deployment istio-sidecar-injector
...
      containers:
      - args:
        - --caCertFile=/etc/istio/certs/root-cert.pem
        - --tlsCertFile=/etc/istio/certs/cert-chain.pem
        - --tlsKeyFile=/etc/istio/certs/key.pem
        - --injectConfig=/etc/istio/inject/config
        - --meshConfig=/etc/istio/config/mesh
        - --healthCheckInterval=2s
        - --healthCheckFile=/health
        - --log_output_level=default:debug
        image: docker.io/istio/sidecar_injector:1.0.2
        imagePullPolicy: IfNotPresent
...

Salve e saia do seu editor. Agora o Kubernetes está fazendo deployment do pod sidecar-injector e o sinalizador depuração deve estar em vigor. Aguarde alguns segundos para o pod estar ativo, então você pode monitorar os logs novamente:

$ pod=$(kubectl -n istio-system get pods -l istio=sidecar-injector -o jsonpath='{.items[0].metadata.name}')
$ kubectl -n istio-system logs -f $pod
Dica

Se mesmo com a saída de depuração ativada você não viu nada relevante em seus logs, isso significa que o pod sidecar-injector não está sendo notificado sobre a criação do pod. Não está sendo invocado para fazer a injeção automática. Isso pode ser devido a uma configuração incorreta em relação ao rótulo do namespace. Verifique se o namespace está rotulado de acordo com o que está no MutatingWebhookConfiguration. Por padrão, o namespace deve ter o rótulo istio-injection=enabled. Verifique se isto foi alterado executando o kubectl -n istio-system edit MutatingWebhookConfiguration istio-sidecar-injector e verifique o campo namespaceSelector.

Quando terminar a sessão de depuração, você poderá editar o deployment novamente e remover esse argumento de depuração.

É isso. Espero que ajude. Sinta-se à vontade para perguntar ou comentar qualquer coisa, aqui ou no twitter! Nos vemos em breve!

22 de December de 2017

CEF on Wayland

TL;DR: we have patches for CEF to enable its usage on Wayland and X11 through the Mus/Ozone infrastructure that is to become Chromium’s streamlined future. And also for Content Shell!

At Collabora we recently assisted a customer who wanted to upgrade their system from X11 to Wayland. The problem: they use CEF as a runtime for web applications and CEF was not Wayland-ready. They also wanted to have something which was as future-proof and as upstreamable as possible, so the Chromium team’s plans were quite relevant.

Chromium is at the same time very modular and quite monolithic. It supports several platforms and has slightly different code paths in each, while at the same time acting as a desktop shell for Chromium OS. To make it even more complex, the Chromium team is constantly rewriting bits or doing major refactorings.

That means you’ll often find several different and incompatible ways of doing something in the code base. You will usually not find clear and stable interfaces, which is where tools like CEF come in, to provide some stability to users of the framework. CEF neutralizes some of the instability, providing a more stable API.

So we started by looking at 1) where is Chromium headed and 2) what kind of integration CEF needed with Chromium’s guts to work with Wayland? We quickly found that the Chromium team is trying to streamline some of the infrastructure so that it can be better shared among the several use cases, reducing duplication and complexity.

That’s where the mus+ash (pronounced “mustache”) project comes in. It wants to make a better split of the window management and shell functionalities of Chrome OS from the browser while at the same time replacing obsolete IPC systems with Mojo. That should allow a lot more code sharing with the “Linux Desktop” version. It also meant that we needed to get CEF to talk Mus.

Chromium already has Wayland support that was built by Intel a while ago for the Ozone display platform abstraction layer. More recently, the ozone-wayland-dev branch was started by our friends at Igalia to integrate that work with mus+ash, implementing the necessary Mus and Mojo interfaces, window decorations, menus and so on. That looked like the right base to use for our CEF changes.

It took quite a bit of effort and several Collaborans participated in the effort, but we eventually managed to convince CEF to properly start the necessary processes and set them up for running with Mus and Ozone. Then we moved on to make the use cases our customer cared about stable and to port their internal runtime code.

We contributed touch support for the Wayland Ozone backend, which we are in the process of upstreaming, reported a few bugs on the Mus/Ozone integration, and did some debugging for others, which we still need to figure out better fixes for.

For instance, the way Wayland fd polling works does not integrate nicely with the Chromium run loop, since there needs to be some locking involved. If you don’t lock/unlock the display for polling, you may end up in a situation in which you’re told there is something to read and before you actually do the read the GL stack may do it in another thread, causing your blocking read to hang forever (or until there is something to read, like a mouse move). As a work-around, we avoided the Chromium run loop entirely for Wayland polling.

More recently, we have start working on an internal project for adding Mus/Ozone support to Content Shell, which is a test shell simpler than Chromium the browser. We think it will be useful as a test bed for future work that uses Mus/Ozone and the content API but not the browser UI, since it lives inside the Chromium code base. We are looking forward to upstreaming it soon!

PS: if you want to build it and try it out, here are some instructions:

# Check out Google build tools and put them on the path
$ git clone https://chromium.googlesource.com/a/chromium/tools/depot_tools.git
$ export PATH=$PATH:`pwd`/depot_tools

# Check out chromium; note the 'src' after the git command, it is important
$ mkdir chromium; cd chromium
$ git clone -b cef-wayland https://gitlab.collabora.com/web/chromium.git src
$ gclient sync  --jobs 16 --with_branch_heads

# To use CEF, download it and look at or use the script we put in the repository
$ cd src # cef goes inside the chromium source tree
$ git clone -b cef-wayland https://gitlab.collabora.com/web/cef.git
$ sh ./cef/build.sh # NOTE: you may need to edit this script to adapt to your directory structure
$ out/Release_GN_x64/cefsimple --mus --use-views

# To build Content Shell you do not need to download CEF, just switch to the branch and build
$ cd src
$ git checkout -b content_shell_mus_support origin/content_shell_mus_support
$ gn args out/Default --args="use_ozone=true enable_mus=true use_xkbcommon=true"
$ ninja -C out/Default content_shell
$ ./out/Default/content_shell --mus --ozone-platform=wayland

16 de October de 2017

Who knew we still had low-hanging fruits?

Earlier this month I had the pleasure of attending the Web Engines Hackfest, hosted by Igalia at their offices in A Coruña, and also sponsored by my employer, Collabora, Google and Mozilla. It has grown a lot and we had many new people this year.

Fun fact: I am one of the 3 or 4 people who have attended all of the editions of the hackfest since its inception in 2009, when it was called WebKitGTK+ hackfest \o/

20171002_204405

It was a great get together where I met many friends and made some new ones. Had plenty of discussions, mainly with Antonio Gomes and Google’s Robert Kroeger, about the way forward for Chromium on Wayland.

We had the opportunity of explaining how we at Collabora cooperated with igalians to implemented and optimise a Wayland nested compositor for WebKit2 to share buffers between processes in an efficient way even on broken drivers. Most of the discussions and some of the work that led to this was done in previous hackfests, by the way!

20171002_193518

The idea seems to have been mostly welcomed, the only concern being that Wayland’s interfaces would need to be tested for security (fuzzed). So we may end up going that same route with Chromium for allowing process separation between the UI and GPU (being renamed Viz, currently) processes.

On another note, and going back to the title of the post, at Collabora we have recently adopted Mattermost to replace our internal IRC server. Many Collaborans have decided to use Mattermost through an Epiphany Web Application or through a simple Python application that just shows a GTK+ window wrapping a WebKitGTK+ WebView.

20171002_101952

Some people noticed that when the connection was lost Mattermost would take a very long time to notice and reconnect – its web sockets were taking a long, long time to timeout, according to our colleague Andrew Shadura.

I did some quick searching on the codebase and noticed WebCore has a NetworkStateNotifier interface that it uses to get notified when connection changes. That was not implemented for WebKitGTK+, so it was likely what caused stuff to linger when a connection hiccup happened. Given we have GNetworkMonitor, implementation of the missing interfaces required only 3 lines of actual code (plus the necessary boilerplate)!

screenshot-from-2017-10-16-11-13-39

I was surprised to still find such as low hanging fruit in WebKitGTK+, so I decided to look for more. Turns out WebCore also has a notifier for low power situations, which was implemented only by the iOS port, and causes the engine to throttle some timers and avoid some expensive checks it would do in normal situations. This required a few more lines to implement using upower-glib, but not that many either!

That was the fun I had during the hackfest in terms of coding. Mostly I had fun just lurking in break out sessions discussing the past, present and future of tech such as WebRTC, Servo, Rust, WebKit, Chromium, WebVR, and more. I also beat a few challengers in Street Fighter 2, as usual.

I’d like to say thanks to Collabora, Igalia, Google, and Mozilla for sponsoring and attending the hackfest. Thanks to Igalia for hosting and to Collabora for sponsoring my attendance along with two other Collaborans. It was a great hackfest and I’m looking forward to the next one! See you in 2018 =)

10 de July de 2017

Da contracultura à cibercultura: Uma reflexão sobre o papel dos hackers.

Da contracultura   cibercultura  uma reflex o sobre o papel dos hackers.

Com o início do século XXI, estamos vivendo um desses raros intervalos na história. Um período em que a base tecnológica das nossas relações em sociedade está — e tudo indica que continuará por um bom tempo — imersa num intenso processo de transformações tecnológicas e culturais. Assim, de forma semelhante ao que aconteceu no século XIX, com a revolução industrial e o surgimento da produção em série mediada por máquinas, as novas tecnologias de informação e comunicação, em especial a internet, revolucionam os meios de comunicação humana, como também alicerçam transformações nas mais diversas áreas da vida em sociedade.

Tendo a liberdade de acesso, produção e compartilhamento de informações como um dos grandes princípios estruturantes, as mudanças propiciadas pelos liames digitais da internet representam até o surgimento de um novo paradigma tecnológico, de uma nova Era Pós-Industrial.

Contudo, cientistas sociais, como Manuel Castells e Fred Turner, nos lembram que não existem revoluções de natureza tecnológica que não sejam precedidas de transformações culturais. Como tecnologias revolucionárias têm que ser pensadas, elas não são o resultado de um simples processo técnico ou incremental, mas sim fruto de pensamentos libertários e subversivos que são, por exemplo, ligados a gestos de rebeldia e desobediência civil. Dentro desse entendimento, esses mesmos autores afirmam que existe uma relação estreita entre os movimentos de contracultura dos anos 60 e a cibercultura libertária dos nossos dias.

Para além dos festivais de música e das manifestações do movimento hippie, os princípios de liberdade de expressão que marcaram essa época também se fizeram presente ao longo de todo o processo de criação e difusão da internet pelo que hoje é denominado de “cultura hacker”. Todavia, antes de seguirmos adiante nessa história, faz-se necessário esclarecer certa ambiguidade ou mal-entendido sobre o termo e a práxis social dos hackers. Afinal, na sua origem, o termo hacker não está associado a indivíduos irresponsáveis que invadem sistemas computacionais de forma ilícita — como é normalmente propagado pela mídia de massa mais tradicional. Esses sujeitos que violam sistemas de segurança e quebram códigos computacionais são, especificamente, denominados de “crackers” e, em geral, são também repudiados pelas comunidades de hackers. É claro que todo “cracker” já foi um hacker e isso possibilita que formadores de opinião — como, por exemplo, o jornalista e produtor cultural Nelson Motta — afirmem que todo hacker seja sim um cracker.

No entanto, de forma contrária a uma visão mais restrita que tenha como base o exemplo de alguns poucos crackers que ganharam fama no mundo por conta de invasões espetaculares em poderosos computadores corporativos, esse artigo tenta ir um pouco além desse entendimento. Em especial, buscamos resgatar a visão do filósofo finlandês Pekka Himanen e os artigos de um dos integrantes da própria comunidade hacker, Eric Raymond, que reforçam a importância desses primeiros “nativos digitais” como uma importante expressão cultural contemporânea de caráter libertário e inovador. Isto porque os hackers estão vinculados a um conjunto de valores e crenças que emergiram, num primeiro momento, das redes de pessoas que desenvolviam softwares e interagiam em redes computacionais em torno da colaboração em projetos de programação criativa. Isso significa, então, partir de um entendimento que essa cultura hacker desempenhou um papel central ao longo da história de desenvolvimento dos principais símbolos tecnológicos da atual sociedade em rede, como os primeiros computadores pessoais (PCs), a internet e os primeiros sistemas operacionais, como o UNIX. E essa cultura criativa perdura até o presente momento de forma pulsante. Afinal, inúmeras pesquisas demonstram como os hackers sustentam o ambiente fomentador de inovações tecnológicas significativas, mediante a colaboração e comunicação on-line, como também acaba permitindo a conexão entre o conhecimento originado em universidades e centros de pesquisas com os produtos empresariais que difundem as tecnologias da informação no “mundo dos átomos” — isto é, na materialidade da economia contemporânea.

Tendo a liberdade técnica de acesso, uso, compartilhamento, modificação e criação como valor supremo, a cultura hacker se manifesta em diversas áreas por meio de uma nova ética de trabalho, que lança alguns “enigmas contemporâneos” sobre o comportamento e as próprias relações sociotécnicas na realidade contemporânea. Mais especificamente, esse suposto comportamento enigmático, em termos de engajamento digital, emerge a partir de questões como: quais os valores que levam hoje milhares de tecnólogos a desenvolverem um software de alta complexidade como o Linux, na maioria dos casos de forma voluntária, além de o distribuírem de forma livre pela internet? Ou ainda, o que exatamente impulsiona milhares de wikipedistas de diversas partes do mundo a se juntarem na internet de forma colaborativa para criar e compartilhar conhecimento de forma livre e gratuita, por meio de um projeto enciclopédico internacional?

Umas das respostas mais encontradas em pesquisas sobre essa temática é que os hackers trabalham e se engajam em projetos dessa natureza, antes de tudo, porque os desafios técnicos e intelectuais são interessantes. Problemas encontrados no processo de criação de um determinado bem causam uma forte curiosidade e atração para essas pessoas, tornando-as sempre ávidas por mais conhecimento para criar ou encontrar uma solução inovadora. Essa atividade de produção exerceria então um poder de fascínio sobre esses sujeitos envolvidos pela cultura hacker, a ponto de o próprio trabalho, em determinadas condições, servir como um momento de se “recarregar as energias” — por mais contraditório que isso possa parecer num primeiro momento. Assim, para definir o princípio que rege as atividades de um indivíduo que se afirma como um hacker, o Linus Torvalds (hacker criador do Linux) acredita que as palavras “paixão” e “diversão” podem descrever bem a força lúdica que move ele a dedicar horas de um trabalho que muitas vezes é empreendido no “tempo livre”.

Por conta disso, não é difícil perceber que esta relação passional com o trabalho não é privilégio dos hackers de computador. Muito ao contrário. Em seu guia Como Tornar-se um Hacker, Eric Raymond também afirma que é possível encontrar outros tipos de hackers entre diversas áreas. “Há pessoas que aplicam a atitude hacker em outras coisas, como eletrônica ou música — na verdade, você pode encontrá-la nos níveis mais altos de qualquer ciência ou arte. Hackers de software reconhecem esses espíritos aparentados de outros lugares e podem chamá-los de ‘hackers’ também — e alguns alegam que a natureza hacker é realmente independente da mídia particular em que o hacker trabalha”.

Por exemplo, há vários pontos de contato entre tecelões, artesãos e a cultura hacker. Isto porque é possível perceber que todos eles (tecelões, artesãos e hackers) comungam de muitos valores inerentes ao trabalho criativo e coletivo, como, por exemplo, o compartilhamento do conhecimento que fundamenta o processo da produção de um bem ou uma obra — além, é claro, do prazer e da alegria inerente ao ato da criação em si. Afinal, o que seria, por exemplo, da gastronomia mundial sem o antigo hábito popular de se compartilhar receitas de culinária para se adaptar e criar novos e saborosos pratos pelos chefes de cozinha.

Richard Stallman, fundador da Free Software Foundation, ressalta, então, que um hacker é antes de tudo alguém que ama o que faz e, por conta disso, busca sempre inovar e explorar novas possibilidades no exercício do seu ofício em colaboração com seus pares. Isso significa dizer que um hacker, como individuo, busca sempre não apenas usar, mas principalmente aprimorar e aperfeiçoar o objeto de sua paixão, no contexto de um setor, organização ou comunidade da qual interage e participa. Para isso, o acesso irrestrito e o compartilhamento do conhecimento associado ao uso e ao processo de produção de um bem em questão é para um hacker, da mesma forma que para seus pares, uma condição vital da sua práxis social.

Dentro dessa perspectiva, esse ímpeto lúdico e colaborativo permite aos hackers romperem com uma dimensão clássica dos sistemas criativos da modernidade industrial: a separação entre quem usa e quem cria, aperfeiçoa ou produz um determinado bem. Em outras palavras, isso significa que a cultura hacker supera a clássica dicotomia entre “criadores” e “usuários”, pois partem de uma (antiga) premissa produtiva: os usuários são a base de toda a organização criativa somente por uma simples razão: todos os criadores eram usuários antes de começarem a contribuir com suas criações.

* Texto originalmente publicado na Revista Objectiva.

13 de March de 2017

Rede Suiça de Educação Artística adere ao Noosfero

 

Foto guerreiro 03

A rede internacional Another Roadmap for Arts Education (Outro Roteiro para a Educação Artística), que reúne educadores/as e pesquisadores/as em museus, universidades, escolas e projetos culturais e educativos passou a utilizar o Noosfero como plataforma de articulação e comunicação entre seus núcleos ao redor do mundo. A rede agrega 22 grupos ao redor do mundo com a proposta de trabalhar a educação artística inserida nas relações sociais e políticas, respeitando os contextos locais.

Another Roadmap surgiu do anseio de educadores/as e pesquisadores/as de fazer uma análise crítica do Roteiro para a Educação Artística da Unesco, definido em 2006, e da Agenda de Seul (2010), uma série de metas mundiais para o desenvolvimento da Arte e Educação. A rede, que deu início à Another Roadmap School (Escola Outro Roteiro), tem a perspectiva de questionar a hegemonia dos conceitos ocidentais de arte e educação e elaborar alternativas e novos paradigmas para as pesquisas e práticas relacionadas à educação artística.

A plataforma utilizada pela rede foi desenvolvida pela Colivre por meio de um serviço prestado à Universidade de Artes de Zurique na Suiça. Por utilizar o Noosfero, a plataforma permite autonomia para os grupos que fazem parte da rede porque possibilita que cada perfil de comunidade e usuário na rede possa ter seu próprio layout customizado além de possuir funcionalidades de blogs, fóruns, agendam, wiki, pastas de arquivos, galeria de imagens, entre outras.

O Noosfero é uma plataforma web livre para a criação de redes sociais autônomas com foco no compartilhamento de conteúdo. Desenvolvido pela Colivre e lançado em 2009 durante o III Encontro Nordestino de Software Livre, o Noosfero já garantiu o primeiro lugar em diversos prêmios nacionais à cooperativa como o 9º Prêmio Cooperativa do Ano em 2014, o Prêmio Pontos de Mídia Livre do Ministério da Cultura em 2015 e o Prêmio Especial Recursos Educacionais Abertos da Revista ARede Educa em 2016.

Para conhecer mais sobre a rede Another Roadmap for Arts Education acesse o site oficial através do endereço http://another.zhdk.ch/.

 

06 de March de 2016

A gota d’água em aplicativos GTK+

Não, eu não estou com a paciência esgotada! 🙂 Hoje estou comemorando que um antigo erro na verificação ortográfica do gedit foi corrigido, de forma que palavras hifenizadas (“corrigi-la-ia”) ou contendo apóstrofo (“d’água”) poderão ser verificadas por inteiro pelo verificador ortográfico.

O corretor ortográfico do LibreOffice para português do Brasil, chamado VERO, já contém palavras hifenizadas há muito tempo. Esse corretor pode ser utilizado por outros aplicativos através da biblioteca de verificação ortográfica Hunspell, e durante algum tempo eu mantive uma adaptação do VERO para Aspell e para Vimspell. (A propósito, ainda preciso de quem me substitua na manutenção dessas adaptações.) Qualquer aplicativo pode usar diretamente o Hunspell ou o Aspell, mas frequentemente os aplicativos utilizam essas bibliotecas através de uma biblioteca intermediária, o Enchant. Tanto o Enchant quanto o Aspell e o Hunspell sabem lidar com apóstrofos e hífens.

Infelizmente, o plugin de verificação ortográfica do gedit não sabia lidar tão bem assim com hífens e apóstrofos no meio de palavras, mesmo utilizando o Enchant. Pode parecer um problema trivial para quem está de fora, mas os desenvolvedores do gedit precisam fazer com que o aplicativo funcione bem para todos os idiomas ao mesmo tempo (com direito a mais de um idioma no mesmo texto), além de contar com destaque de sintaxe e outros recursos.

Em setembro do ano passado, um novo desenvolvedor resolveu adotar o plugin de verificação ortográfica do gedit, e trabalhar nele como uma biblioteca externa, chamada gspell. O gspell poderá ser utilizado por qualquer aplicativo baseado em GTK+, e sua versão 0.2.x deverá estar disponível com o GNOME 3.20.

Ainda não tive a oportunidade de testar o gspell, e não sei quais aplicativos do GNOME efetivamente utilizarão o gspell em sua nova versão. Mesmo assim, fico feliz em saber que o gspell aprendeu a lidar com hífens e apóstrofos no meio da palavra! Merci beaucoup, Sébastien Wilmet! Thank you!

23 de January de 2015

A successful Git branching model!


Warning: Missing argument 2 for wpdb::prepare(), called in /var/www/html/blog/wp-content/plugins/category-icons/category_icons.php on line 1338 and defined in /var/www/html/blog/wp-includes/wp-db.php on line 1222

Good explanations to have successful with GIT branching model.

16 de December de 2014

The Infamous Windows “Hello World” Program


The Infamous Windows “Hello World” Program (A good and archaeological post by Petzold)

03 de December de 2014

New tablet UI for Firefox on Android

The new tablet UI for Firefox on Android is now available on Nightly and, soon, Aurora! Here’s a quick overview of the design goals, development process, and implementation.

Design & Goals

Our main goal with the new tablet UI was to simplify the interaction with tabs—read Yuan Wang’s blog post for more context on the design process.

In 36, we focused on getting a solid foundation in place with the core UI changes. It features a brand new tab strip that allows you to create, remove and switch tabs with a single tap, just like on Firefox on desktop.

The toolbar got revamped with a cleaner layout and simpler state changes.

Furthermore, the fullscreen tab panel—accessible from the toolbar—gives you a nice visual overview of your tabs and sets the stage for more advanced features around tab management in future releases.

Development process

At Mozilla, we traditionally work on big features in a separate branch to avoid disruptions in our 6-week development cycles. But that means we don’t get feedback until the feature lands in mozilla-central.

We took a slightly different approach in this project. It was a bit like replacing parts of an airplane while it’s flying.

We first worked on the necessary changes to allow the app to have parallel UI implementations in a separate branch. We then merged the new code to mozilla-central and did most of the UI development there.

This approach enabled us to get early feedback in Nightly before the UI was considered feature-complete.

Implementation

In order to develop the new UI directly in mozilla-central, we had to come up with a way to run either the old or the new tablet UIs in the same build.

We broke up our UI code behind interfaces with multiple concrete implementations for each target UI, used view factories to dynamically instantiate parts of the UI, prefixed overlapping resources, and more.

The new tab strip uses the latest stable release of TwoWayView which got a bunch of important bug fixes and couple of new features such as smooth scroll to position.


Besides improving Firefox’s UX on Android tablets, the new UI lays the groundwork for some cool new features. This is not a final release yet and we’ll be landing bug fixes until 36 is out next year. But you can try it now in our Nightly builds. Let us know what you think!

27 de November de 2014

Joining Facebook

I am really excited to announce that I’m joining Facebook in January! I’ll be bootstrapping Android UI efforts—frameworks and user-facing stuff—in the London office. There are still a lot of details to sort out but that’s the general plan.

Why Facebook? They have an amazing hacker-driven culture, they’re striving to do open source the right way, there’s a lot of space for experimentation, and they have massive reach in the Android space.

I’m really looking forward to learning a lot at Facebook. And there is so much to be done! I can’t wait to start :-)

08 de April de 2012

Mudança

Prezados leitores e agregadores, este blog está se mudou para https://leofontenelle.wordpress.com. Atualizem seus marcadores/favoritos com urgência, pois o domínio http://leonardof.org em breve deixará de me pertencer.

É uma pena que eu não tenha conseguido o subdomínio leonardof.wordpress.com. Tenho muito carinho por “leonardof” desde que esse se tormou o nome da minha conta no SVN (hoje Git) do GNOME. Só que eu preciso dedicar menos tempo em manutenção de webapps, domínios etc, para ter mais tempo para as atribuições profissionais e pessoais.

Espero ter uma novidade em breve para contar a vocês, então não sumam!

07 de April de 2011

O GNOME 3 é espetacular!!!

Eu sou GNOME. E você?
I am GNOME

21 de December de 2009

Barcelona campeão mundial

Parabéns ao Barcelona pelo título conquistado. Eu cheguei a pensar que daria Estudiantes.

Enquanto eles comemoram o primeiro título, lembro que já conquistamos três vezes (inclusive uma delas contra eles).

Um fato que eu não sabia e agora sei é que no mesmo ano da disputa ganhamos outro título (do Torneio Teresa Herrera) contra eles. E de 4 a 1!!! Na época o Barcelona era bem "maior do mundo" do que é hoje.

Saudações tricolores!

10 de June de 2007

Violent swerves in life

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.

23 de September de 2006

Thanks, Murphy!

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…