Filipe Saraiva's blog

Tecnologia, sociedade e política.

Archive for the ‘Software Livre’ Category

KDE packagers: give some love to Cantor

with 6 comments

python2_select

I have some posts to write about Cantor but first I would like to request a help to KDE packagers of several Linux distros around the world.

I received some mails from users asking “how can I use python in Cantor?” or “where is python support in Cantor?”. Well, python2-backend is available in Cantor since KDE 4.12 release. If you is using KDE >= 4.12 but you can not to use python in Cantor, maybe the package was not build correctly.

python 2 development library (commonly packed as python-devel in some Linux distros) is required to build python2-backend. python 2 is required to use Cantor with python 2.

Then if you are a Cantor user and can not to use Cantor with python, please write a bug report in the bug management system of your distro. You can to put a link in the bug report to this post too.

Anyway, if your distro bring or not bring python2-backend, write a comment below and I will make a table with this information.

Written by Filipe Saraiva

April 24th, 2014 at 12:47 am

Haverá futuro para o Diaspora?

with 7 comments

Diaspora é aquela rede social que foi financiada via crowdfunding no Kickstarter e fez muito barulho na imprensa do mundo todo por conta do discurso que seus criadores utilizavam: “Diaspora será o Facebook killer”. Mas isso foi em 2010.

Perambulo pelo Diaspora desde a versão de testes, lançada em 2011. Na época você tinha que conseguir um convite para ter uma conta na instância (também chamada de pod) mantida pelo time de desenvolvedores, o joindiaspora. De lá para cá pouca coisa mudou quando falamos em funcionalidades – o que contrasta bastante com as grandes mudanças que ocorreram no gerenciamento do projeto, onde hoje os quatro programadores que recorreram ao crowdfunding para levantar a grana que pagaria o desenvolvimento já não trabalham mais com a plataforma, “doada para a comunidade” há um ano e meio, e que agora depende exclusivamente desta para avançar.

Antes de começar o artigo de fato, quero dizer aos amigos que não me tomem como pessimista ou alguém do gênero – ou pior, como alguém que não acredita que comunidades podem criar e gerir bons projetos de software livre. Eu participo ativamente como desenvolvedor em pelo menos dois projetos comunitários (a saber, KDE e Mageia) e sei que, sim, é possível termos bons projetos baseados em comunidades. Mas o que acompanho do Diaspora, em termos de desenvolvimento, não me deixa muito animado. Por outro lado, talvez os brasileiros que nos últimos meses lotaram o Diaspora possam dar sua contribuição para não deixar a plataforma morrer.

De qualquer forma, caso o Diaspora não decole, ainda temos muitos bons projetos de redes sociais descentralizadas, federadas, em software livre, para podermos migrar.

Diaspora – funcionalidades

Para um projeto que se propôs a desbancar o Facebook, faltam muitas funcionalidades no Diaspora. Basicamente você tem o stream (a sua timeline) com as pessoas que você segue. Você também pode seguir tags – a rede social permite a inclusão delas nos posts. E quando você adiciona alguém, a pessoa adicionada não o segue automaticamente de volta. Sempre que adicionar alguém você colocará o contato em um ou mais aspects – conceito criado aqui, depois copiado como Listas no Facebook ou o Círculos no Google+. Os posts podem ser escritos usando a linguagem de marcação Markdown – não há um editor WYSIWYG para usá-la.

Olhando bem para esse conjunto de funcionalidades, o Diaspora lembra muito mais o Twitter do que o Facebook, porém sem a limitação de caracteres do primeiro.

A partir das funcionalidades presentes, podemos listar as funcionalidades que mais fazem falta no projeto: não há suporte a grupos; não há chat; não há uma API que permita o desenvolvimento de clientes ou outras aplicações que utilizem o Diaspora; as tags não são federadas – portanto você só verá as tags dos perfis que estão no mesmo pod que você; entre outras.

Caramba, não há uma funcionalidade para importar um perfil em outro pod! Ou seja, você tem uma rede descentralizada, mas o seu perfil está amarrado ao pod no qual você o criou até o fim daquele pod. Você conseguirá exportar seu perfil, mas servirá apenas como backup em algum canto perdido do seu HD.

É um tanto decepcionante constatar isso, em especial quando você sabe que em outras redes sociais livres essas funcionalidades estão presentes, ou quando você conhece a história de um famoso fork do Diaspora chamado Diasp0raca.

Esse fork era mantido por um desenvolvedor chamado Pistos. Nenhuma de suas contribuições de funcionalidades foram aceitas pelos desenvolvedores do projeto original, mas Pistos mantinha-as em seu fork e também gerenciava um pod que rodava o seu código – que ficava em http://diasp0ra.ca/. Com o tempo, devido à presença dessas funcionalidades, outros pods adotaram o código de Pistos.

Para resumir, o Diasp0raca tinha grupos, chat, possibilidade de importar os contatos de um perfil, CSS customizável, preview de posts, entre outras funcionalidades. Inclusive ele estava trabalhando em uma API! Tudo isso já funcionava no início de 2012. Mais de dois anos depois, e a única dessas funcionalidades disponível no Diaspora é… o preview de posts.

Pistos acabou rompendo relações com o Diaspora após o anúncio de que os desenvolvedores desta fariam uma profunda alteração no protocolo de comunicação, o que cortaria a comunicação entre diversos pods e outras redes sociais que conseguiam se comunicar com a rede Diaspora (por exemplo, o Friendica), sem qualquer discussão com os desenvolvedores interessados e sem disponibilização de documentação. O hacker chutou o balde e lançou um novo projeto de redes sociais distribuídas, o LiberTree.

Diaspora – gerenciamento do projeto

Como já comentado, o Diaspora começou como o projeto de um pequeno grupo de desenvolvedores – quatro caras. Apesar do desenvolvimento ser livre e colaborativo, o gerenciamento do projeto era bastante centralizado nesse time, e poucas funcionalidades criadas por desenvolvedores externos foram absorvidas pelo projeto.

A impressão que fica é que eles tentaram criar um modelo de negócios no estilo do WordPress, mas não tiveram êxito. Relatório de dívidas quanto à manutenção do pod público (o joindiaspora), a falta de um plano de negócios para captar recursos, a criação de um novo projeto baseado na criação de memes (!!!), e o triste suicídio de Ilya, um dos fundadores, acabaram levando o grupo à decisão de desistirem do projeto e a tomarem a típica atitude de uma empresa que não está mais interessada em investir em um software livre antes desenvolvido por ela: “doaram o projeto para a comunidade”. Era agosto de 2012.

Desde então o Diaspora tem sido gerenciado por um grupo de desenvolvedores reunidos sob a Diaspora Foundation. Seus principais canais de discussão sobre o desenvolvimento da ferramenta são o grupo de e-mails, a wiki, a ferramenta de deliberação loomio, e o repositório do código hospedado no github.

O que sinto ao visitar esses lugares é um projeto ainda perdido, com pouco gás, sem aqueles desenvolvedores que se metem a criar grandes funcionalidades, que dedicam seu tempo a fazer o projeto caminhar de verdade. Claro que o pessoal está trabalhando, e o trabalho deles deve ser agradecido – mas a maior parte são ainda em pequenos detalhes, coisas pontuais diante das necessidades da rede.

Olhe por exemplo a lista de e-mails de desenvolvimento: você pode rolá-la e não verá nada de discussão sobre qualquer funcionalidade que aponte maneiras de implementá-la. Apenas diálogos sobre algo que precisa ser feito, ou propostas de implementações de funcionalidades pequenas.

No loomio também é assim. Há importantes tópicos abertos, mas que tiveram início há muito tempo – vários meses e alguns com quase um ano de idade. Há discussão no período imediato à abertura do tópico, depois ele esfria. Passam-se meses, depois volta um pouco de diálogo, apenas para morrer em seguida.

Enquanto escrevia esse post aconteceu algo que ilustra bem essa situação: compartilhei um merge request no github com código para prover acesso à aplicações de terceiros para o Diaspora – ou seja, boa parte de uma API. O Diaspora precisa disso para facilitar que seus usuários gerem e direcionem conteúdo para a rede. Há um serviço, o PaperBod, que direciona para o Diaspora o stream de sua conta do Twitter, Facebook, ou mesmo um feed RSS. O que ele precisa para funcionar? O seu login e a sua senha! Que dizer de uma rede social cujo discurso é baseado em maior privacidade e controle dos dados pelo usuário, onde você entrega o login e senha do seu perfil para uma aplicação?

Enfim, voltando à API, o desenvolvedor abriu o pedido de merge 5 meses atrás. O código foi dado como terminado por outro desenvolvedor há um mês, seguido de um pedido de revisão. Desde então, não houveram quaisquer manifestações – o código está lá, “flutuando”.

O Diaspora tem pela frente grandes desafios se ele quiser manter-se relevante. Há a necessidade da definição de um protocolo de comunicação que possibilite as diversas funcionalidades esperadas pela rede. Há discussões sobre o uso de protocolos já existentes, como o tent.io, zot2, ou pumpio, por exemplo, mas são discussões antigas, que não definiram a direção que o desenvolvimento deve tomar e que não produziram resultado até o momento.

Por conta dessas indefinições, eu tendo a ver os desenvolvedores do Diaspora como programadores que querem sim ter uma rede social distribuída funcionando, mas que eles não dão a ela uma importância central para o contexto das redes sociais hoje, mais ou menos como os históricos desenvolvedores de software livre encaravam suas aplicações como substitutas para os softwares proprietários que eram comumente utilizados, principalmente no início da história do movimento software livre. Essa atitude true é mais presente, penso eu, nos desenvolvedores do Friendica/Red – basta citar que os desenvolvedores do core dessas redes não tem conta em nenhuma outra rede social. Para eles, o Friendica/Red não é um “acessório”, algo que eles usam em paralelo com as redes centralizadas. Eles são obcecados com privacidade, segurança de dados – o software deles tem que funcionar porque eles não tem alternativa, não estão dispostos a utilizar uma rede social proprietária, centralizada, que terá acesso aos dados deles e de quem eles levarem para lá.

Haverá futuro para o Diaspora?

Apesar do post em sua maior parte apresentar uma visão negativa do Diaspora, essa rede social conseguiu algo que nenhuma outra rede social descentralizada conseguiu – ela tem muitos usuários. Certamente devido ao grande barulho e propaganda que uma rede autodenominada anti-Facebook conseguiu na mídia, mas também por pessoas dedicadas que subiram servidores, colocaram o projeto debaixo do braço, e foram fazer palestras/montar stands/dar entrevistas/participar de reportagens e todo o mais do bom trabalho de promoção que todo ativista de software livre, quando se encanta por determinado projeto, se propõe a fazer.

E sabemos que o que atrai usuários para uma rede social é a presença de outros usuários – que geram conteúdo e atrai atenção para a rede, resultando em mais conteúdo que atrairá a atenção de mais usuários que irão gerar mais conteúdo… e por aí segue.

Existem redes sociais hoje que entregam as funcionalidades mais desejadas que não existem no Diaspora. O Friendica é uma delas, que utilizei por quase um ano, e era ótimo como tudo funcionava bem. Mas acabei saindo porque só me relacionava com outras 2 pessoas. Enquanto isso continuo no Diaspora, mesmo tendo consciência de todo o cenário que descrevi aqui – querendo ou não, lá ainda existe alguma interação.

No final de 2013 um pod brasileiro, o DiasporaBR, foi lançado e enquanto escrevo essa frase ele conta com 6475 usuários. É muita gente. 1% disso dá 64.75 pessoas, com certeza um número muito maior que os atuais desenvolvedores do Diaspora. Se 0.1% desses usuários se tornarem desenvolvedores (6 pessoas e meia =D), com certeza será uma boa arrancada para a rede social.

O que fica para nós, ativistas do software livre, é uma encruzilhada complicada. O Diaspora tem mais usuários, mas se ele não avançar e prover novas funcionalidades, esses perfis serão apenas números sem pessoas por trás. Mas a alternativa de migrar todo esse contingente para uma rede social que funciona hoje, é uma alternativa viável? Se sim, quem está disposto a bancá-la – na forma de disponibilizar servidores e mão de obra técnica?

Novidades no Editor de Scripts do Cantor

without comments

Um post rápido sobre o Cantor antes da última metade das festas de Carnaval.

KDE 4.13 está com as funcionalidades congeladas agora, e tive tempo de desenvolver algumas melhorias para o editor de scripts do Cantor, que estará disponível no próximo lançamento estável do KDE por volta de 16 de abril.

Agora, os backends para Python 2 e Scilab tem suporte ao editor de scripts! Veja algumas imagens:

python_script_editorEditor de scripts do Cantor para Python 2

scilab_script_editor Editor de scripts do Cantor para Scilab

Você pode acessar o editor de scripts via barra de menu Exibir -> Mostrar Editor de Script. O editor é baseado em kate-part, então ele disponibiliza destaque de sintaxe, numeração de linhas, mini-mapa do texto, e todas as outras coisas legais disponíveis no Kate. Você também tem um botão Executar Script que, após pressionado, carrega o script na área de trabalho do Cantor, como pode ser visto nos exemplos.

Há outras novidades também para os demais backends do Cantor. O Editor de Scrips agora carrega o destaque de sintaxe padrão para cada backend – nas versões anteriores, isso não acontecia. E também, se você pressionar o botão Novo, o novo editor já terá o destaque de sintaxe padrão funcionando também.

Estas são as novidades do meu trabalho no Cantor para o KDE 4.13. Eu pretendo melhorar o backend para Python 2 e o editor de scripts em lançamentos futuros.

Mas agora é hora de aproveitar o restinho do carnaval nas festas de rua do Brasil. Feliz Carnaval! ;)

Cantor’s script editor news

with 4 comments

A small blogpost about Cantor before Brazilian Carnival parties.

KDE 4.13 is feature freeze now and I developed some improvements in Cantor’s script editor. It will be available in next KDE stable release around April 16.

Now Python 2 and Scilab backends have support to script editor! See some pictures:

python_script_editorCantor Script Editor for Python

scilab_script_editor Cantor Script Editor for Scilab

You can access script editor in menu bar View -> Show Script Editor. The script editor is based in kate-part, so you have syntax highlighting, line numbering, mini-map, and all cool stuffs from Kate. You have a Run Script button too, so you can just push this button and the script will be load in Cantor worksheet, as you can see in examples.

There is news for others Cantor backends too. Now script editor load default syntax highlighting for each backend – in old versions it did not happen. And, if you push New button, the new script editor will have the default syntax highlighting working too.

It is the news about my work in Cantor for KDE 4.13. I intent improve Python 2 backend and script editor for future releases.

But now it is time to go to Brazilian street parties! Happy Carnival! ;)

Ajude a criar a programação do FISL 15

without comments

O Fórum Internacional de Software Livre (FISL) chega à sua 15ª edição e continua sendo referência para a comunidade de software e cultura livre latino-americana.

Você pode tanto participar da programação do FISL quanto ajudar a criá-la. Diversas modalidades de submissão de atividades encontram-se abertas, e você pode clicar nos links abaixo para saber mais informações.

A Chamada de Palestas foi prorrogada até o dia 27 de fevereiro, mesmo já havendo 413 propostas cadastradas! Esta é a forma de submissão de atividade mais convencional onde você descreve um tema sob qual irá palestrar.

A Chamada para Encontros Comunitários é voltada para comunidades de usuários/desenvolvedores que queiram fazer um pequeno encontro no espaço do FISL. O tempo disponibilizado pode ser um pouco maior que o de uma palestra (até 1 hora e 40 minutos de atividade). Submissões até dia 10 de março.

Uma das melhores atrações do FISL com certeza é o espaço dos grupos de usuários. Se você quer ter a sua comunidade por lá fique atento ao prazo e requisitos da Chamada de Grupos de Usuários. As propostas para participação desse espaço vão até dia 10 de março.

A Chamada para o Workshop de Software Livre (WSL) é o lado mais acadêmico do FISL. Aqui, pesquisadores acadêmicos do software livre, cultura livre, e mais, apresentam resultados de suas pesquisas em painéis científicos divididos por temas. Há diversos tipos de submissão de artigos e o deadline vai até dia 8 de março.

Mandem suas atividades e nos encontramos no FISL! ;)

Algumas novidades do Mageia 4

with 2 comments

E o Mageia chega ao seu quarto release estável!

Entre as novidades temos o MageiaWelcome – um aplicativo que executa na inicialização da distro e dá dicas sobre instalação de pacotes adicionais e canais de suporte do Mageia; a disponibilização dos ambientes gráficos Mate e Cinnamon; o port das ferramentas drak para GTK+ 3; a possibilidade de criar pen drives bootáveis através de uma nova ferramenta chamada isodumper; bash-completion instalado por default; a adoção do novo esquema de nomes para interfaces de rede; e mais.

Também temos versões mais modernas de softwares como KDE (4.11.4), GNOME (3.10.2.1), LXDE, XFCE (4.10), Razor-QT, Libre Office (4.1.3.2), RPM (4.11.1), systemd 208, e outros. O GRUB ainda é usado por padrão, mas o GRUB 2 está disponível também. O kernel entregue é o 3.12.8.

Além das novidades listadas temos a atualização de diversos pacotes e a disponibilização de novos. Você pode ver neste quadro uma comparação entre os pacotes do Mageia 3 e Mageia 4.

Especificamente pro pessoal do Python, essa versão do Mageia adicionou o suporte a PythonByteCompiling.

E sobre os pacotes que mantenho na distro, tenho algumas novidades: o pacote abntex2 foi incluído no texlive; os pacotes swi-prolog agora seguem a convenção de nomes de pacotes crossdistro do projeto; disponibilizei 3 lançadores full-screen para o KDE (a saber: plasma-applet-homerun, plasma-applet-simplewelcome e plasma-applet-takeoff); o tema Caledonia, surgido no Chakra Linux, agora pode ser instalado no Mageia (plasma-desktoptheme-caledonia e plasma-desktoptheme-caledonia-wallpapers); temos um cliente para pump.io chamado Dianara; um aplicativo para conversas privativas, Retroshare; um aplicativo para escrita de textos voltado a escritores, Plume-Creator; e mais. Ao todo estou mantendo 13 pacotes, um acréscimo interessante comparado aos 2 disponibilizados no Mageia 3.

Qualquer dúvida ou necessidade de suporte em português, procure a comunidade Mageia do Brasil e ajude o Mageia a ser cada vez melhor.

Leia mais detalhes sobre esse lançamento, bem como instalação e atualização via Mageia 3, na nota oficial traduzida.

Written by Filipe Saraiva

February 1st, 2014 at 7:35 pm

Cantor: Python 2 backend feature tour

with 12 comments

Introduction

python2_selectCantor backend selection screen

In 2013 I developed a Python 2 backend for Cantor, a project funded in part by Google Summer of Code. Now this backend is available in Cantor released in KDE 4.12.

Cantor is a mathematical/scientific programming software, a frontend providing IDE features (syntax highlighting, tab-complete, variables management, and more) and a advanced terminal. Cantor support a lot of mathematical engines like Octave, Sage, Maxima, Kalgebra, Qualculate, R, Scilab (developed by me too), and now, Python 2. You can see Cantor as a Matlab-like software, but it uses other mathematical environment/software as programming language.

This post I will do a “feature tour” in Python 2 backend to show Cantor software for scientific python developers community.

Initial Screen – Syntax Highlighting and Tab Complete

python2_initialscreenCantor initial screen

After select the Python 2 backend, Cantor will show the initial screen. This window have a big widget for the Python 2 terminal, and two side panels – one to show the Python 2 help and the other to variables management.

Let’s see some commands inputs in the terminal:

python2_syntaxSyntax highlithing

Cantor is highlighting the Python 2 syntax and, in side panel, you can see the variables created.

Now, let’s create new variables with similar names to test the tab complete. See the picture below:

python2_completeTab complete for variables

After create variables variable_x, variable_y e variable_var, we can write in terminal var and type tab key twice – Cantor will show the variables and functions with the same piece of word. Tab complete is available for module functions too.

python2_complete2Tab complete for module functions

Cantor show error messages in terminal too. Next figure show a import error:

python2_errorError message

You can save the terminal state or just the input commands and their outputs in a file. Cantor allows upload/download a terminal example for a remote server. You can explore this features in “File” menu.

Help Panel

Cantor shows Python help from help command in a side panel. The picture below shows the help for complex class:

python2_helpHelp panel

Cantor uses Qt/KDE technologies, so you can change the window format moving the side panels. Next picture show the window with the variables management in the left side and the help panel in the right side.

python2_help_completePanels in different sides

Variables Management

python2_variables Variables management panel

Variables management panel shows the variables created in Cantor session, showing their labels and values. The panel have some additional functions too, in buttons bottom the widget. These functions are, from left to right, Add variableLoad variables, Save variables, and Clear all variables.

Add variable just open a pop-up window to input a label and a value to a variable.

Load variables and Save variables uses shelve module to data persistence. When the buttons are clicked, Cantor loads scripts to, in first case, read and load variables to the session, and, in second case, save the python dictionary in a file. The figures below show this operations:

python2_save_variablesSaving variables

python2_load_variablesLoading variables

The function Clear all variables delete each variable from Python dictionary. The code is below:

python_backend_variable_management_usecase6Graphics

python_command_to_plotCode for graphic creation using matplotlib

python_plot_resultGraphic loaded in Cantor

The figures below show the graphic loaded in Cantor worksheet. When a session is exported, the graphic will be exported too. This feature can be configured to create the graphics in a new window – this is the default option.

Conclusion and Future

This is the first stable version of Python 2 support in Cantor. It is working good, but you can see the bug presence in some parts of software.

I would like to see some feedbacks from mathematical/scientific programming python community. I am not a “pythonist”, so the python community can find bugs and strange behaviours in the software better than me. I would like to see some feature suggestions too.

For the next version, Python 2 backend will have support to script editor – unfortunately, I can not develop it for this release.

If you are interested in the backend development, my blog have a set of posts (in Portuguese and English) about it. You can download the source code in Cantor repository – the license is GPLv2. And you can submit a bug report in KDE bugzilla.

And you can contact me in comments area below or in my mail address filipe at kde.org.

Written by Filipe Saraiva

January 16th, 2014 at 10:42 am