07 de October de 2019

GNOME 3.34 Release Party in Brno, Czech Republic

In September 25th we had once more a local meetup in Brno to celebrate another fantastic GNOME Release!

GNOME “Thessaloniki” 3.34 is out now and will be reaching distros in the following months. This version is the result of the work of approximately 777 contributors in the last six months. For more details, check out the release notes.

Our Brno celebrations this cycle were held in Schrott, a place with a wide variety of beers and a neat industrial decor. Dominika Vagnerova arranged delicious GNOME themed cupcakes with eatable app icons that went along pretty well with the drinks.

This was an excelent opportunity for us to sit down, relax, and chat about GNOME, Free Software, and all things that bring us together.

More photos of the event are available in our shared album, including ~exclusive~ pictures of application maintainers eating their apps’ cupcakes. :-)

Thanks everyone that showed up, special thanks to Dominika for organizing the event and Rishi for the photos. Stay tuned for 3.36!

02 de October de 2019

GUADEC 2019

Meeting my fellow GNOMies is something I look forward to every year. For eight years now I have traveled to participate in GUADEC and returned home with my head thinking of next year’s edition of the conference.

This year, I was busy with lots of activities, but still, I managed to chill with the friends I work with online throughout the whole year.  Putting faces into new names is also something very pleasant in these opportunities.

In the pre-registration party, I hosted a “Newcomers dinner“. Not many people could attend because of their personal travel plans, but those that participated were excited about being at the conference and getting to know so many cool people.

Besides that, it was the first GUADEC that we had a trained Code of Conduct Incident Response Team. We did an extensive training workshop with Otter Tech. Highly recommended!

Right at the first talks day, I hosted the interns’ lightning talks, that thanks to the amazing local team, are recorded and available online. The audience (and myself) were enthusiastic about hearing from the interns. After a few years of organizing these activities, I can still remember myself being an intern and giving my lightning talk back in 2012. Time flies! :-)

The quality of talks is always outstanding, so I listed below the ones I attended and recommend watching online:

  • Desktop Secrets Management for the Future by Daiki Ueno: I have lately been heavily interested in application sandboxing, so it was great catching up with Daiki’s work and ideas for our keyring story.
  • Managing GNOME Sessions with Systemd by Benjamin Berg and Iain Lane: It is being great and educative to follow their progress throughout the years on this task. The cherry on the cake is seeing this work landing and explained in Benjamin’s blog post.
  • Designing Multi-Process Application Security by Christian Hergert: Watching Christian talk is always exciting and educational. We are lucky to have such skillful developer in our project, and I definitely learned valuable lessons on application security.
  • Portals – Principles and Practice by Matthias Clasen: As I mentioned above, I have been lately interested in application sandboxing, so I couldn’t miss Matthias’ talk on Portals. It is so nice to see our application ecosystem evolving with Flatpak and its technologies.
  • GNU HEALTH: The Fight for our Rights in the Public Health System by Luis  Falcón: I personally care a lot about such social issues especially for being myself originally from the developing world, where people often don’t enjoy the same rights people in the developed world take for granted. The keynote was very well chosen.
  • Environmentally Friendly GNOME by Philip Withnall: IMPORTANT! We are running out of time to stop climate change, and I think every segment of society needs to discuss the issue. I hope to see the ideas discussed in this talk brought forward in our community.
  • Simple is Hard – Creating Beautiful App Icons by Jakub Steiner: Jimmac is so creative and talented that I can’t ever miss his talks. It is great to work with the design team on a daily basis, and this was a good opportunity to better understand their creative processes.
  • Accessibility Features for Mutter/GNOME Shell on Wayland by Oliver Fourdan: This work is very important. Oliver has made significant progress in shrinking the accessibility gap we currently have. Thanks for that!
  • Designing GNOME Mobile Apps by Tobias Bernard: Exciting work! It was great to see their progress on making GNOME apps adaptative. I hope this can make our platform even more attractive to vendors interested in building mobile OSes.
  • The Growth of GNOME by Neil McGovern: It is very reassuring listening to Neil describe the plans of growth for the GNOME Foundation.
  • Lightning Talks: It is always fun to see fellow GNOMies delivering their talk considering the lightning talks’ time constraint. :-D

During the BoF days, I conducted the Newcomers workshop, where we had various participants learning hands-on how to make their first code contribution to the GNOME project. Thanks everyone that showed up to participate and to help newcomers. I hope we can improve and repeat the workshop all over the world. GNOME.Asia will have its edition of the Newcomers workshop, so if you will be around in Gresik, don’t miss it!

In the Boxes BoF we discussed a roadmap to land some highly anticipated features such as UEFI support, Import/Export VMs, etc… Stay tuned here and also in the @BoxesGNOME Twitter account, where I have been doing outreach for our project by interacting with a part of our user base [wherever they are].

The social events were a blast. We had delicious food, great music, and passionate conversations at the Gala Dinner. The Picnic Day was fun and relaxing. The Museum BoF was enjoyable and nerdy (how I like it ;-)).

Checkout the photos!

Thanks to my employer, Red Hat, for sponsoring my trip and accommodation in the beautiful Thessaloniki!

30 de September de 2019

Sprint 5: stability, stability, stability

The Sprint series comes out every 3 weeks or so. Focus will be on the apps I maintain (Calendar, To Do, and Settings), but it may also include other applications that I contribute to. Calendar GNOME Calendar saw a moderately busy spring, mostly focused on landing a few outstanding 3.32 merge requests (thanks Michael Catanzaro for writing … Continue reading Sprint 5: stability, stability, stability

05 de August de 2019

App Grid in GNOME Shell

GNOME Shell is the cornerstone of the GNOME experience. It is the part of the system where the vast majority of user interactions takes place. Windows are managed by it. Launching and closing applications as well. Workspaces, running commands, seeing the status of your system — GNOME Shell covers pretty much everything. One interesting aspect … Continue reading App Grid in GNOME Shell

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!

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!

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…