Ir para o conteúdo
Mostrar cesto Esconder cesto
ou

Software livre Brasil

Tela cheia
 Feed RSS

Liberdade na Fronteira

27 de Maio de 2009, 0:00 , por Desconhecido - | Ninguém está seguindo este artigo ainda.

De volta a Belém

12 de Janeiro de 2018, 11:50, por Filipe Saraiva's blog - 0sem comentários ainda

30 anos atrás uma jovem Dêka, cabelos curtíssimos, saía de Belém para passar férias em São Geraldo do Araguaia. A partir dessa viagem, seus dias por Belém se resumiriam apenas a curtas temporadas.

Numa época onde era mais comum aos homens assumirem seus filhos e mulheres, minha mãe saiu de São Geraldo com uma família própria, transformada mãe e esposa, se mudando para o Maranhão e em seguida o Piauí.

Filha de uma família enorme, minha mãe sempre guardou saudades da cidade onde nasceu e cresceu. Belém tornou-se nossa cidade de férias, dias divertidos para nós; para ela, dias de acalmar o coração.

29 anos depois da viagem a São Geraldo me vejo chegando a Belém, de mudança. Sem qualquer intenção ou planejamento, nada próximo de qualquer “desejo morar em Belém algum dia”, fui aprovado em exame da UFPA no rescaldo dos concursos no final do turbulento 2015.

Minha vinda a Belém me fez pensar muito em minha mãe. Era como se, de alguma forma, por meu intermédio, ela voltasse para a cidade onde nasceu, cresceu e amou. Ela deixou a cidade por minha causa, e agora, quase 3 décadas depois, o motivo que a fez retirar-se daqui vem a cidade para morar.

O tempo que passo em Belém é o tempo onde tento descobrir a cidade e minha mãe. Como era a cidade por onde ela caminhou? Como eram as ruas, as lojas? O que ela gostava de fazer? A cada esquina de Belém, me pergunto se minha mãe conhecia aquele lugar. Em que praças deixava seus sentimentos?

O tempo que passo em Belém é o tempo onde tento descobrir a cidade, minha mãe, e eu mesmo.



Mestrado em Ciência da Computação na UFPA 2018: Inteligência Computacional e Smart Grids

10 de Janeiro de 2018, 15:04, por Filipe Saraiva's blog - 0sem comentários ainda

O PPGCC-UFPA está com o processo seletivo para o mestrado 2018 aberto e na oportunidade oferto uma vaga sob minha orientação.

A linha de pesquisa é inteligência computacional aplicada a smart grids. Ainda não delimitei uma técnica específica e o tipo de trabalho a ser desenvolvido. Nos últimos anos venho trabalhando bastante com sistemas multiagentes, mas a depender do candidato podemos focar em métodos metaheurísticos de otimização ou deep learning.

A pesquisa será desenvolvida em Belém, portanto o candidato deverá morar na cidade durante o período. As bolsas serão distribuídas apenas ao final do processo de seleção.

Aos interessados, todas as informações sobre o ingresso e processo seletivo estão disponíveis no edital. Maiores informações sobre a área de pesquisa, por favor verifique artigos publicados na minha página pessoal. Para qualquer informação ou dúvida, por favor me contate via e-mail através do endereço saraiva em ufpa.br.



Discussing the future of Cantor

7 de Janeiro de 2018, 14:07, por Filipe Saraiva's blog - 0sem comentários ainda

Hello devs! Happy new year!

It is common to use the new year date to start new projects or give new directions for old ones. The last one is the case for Cantor.

Since when I got the maintainer status for Cantor, I was working to improve the community around the software. Because the great plugins systems of Qt, it is easy to write new backends for Cantor, and in fact in last years Cantor reached the number of 11 backends.

If in a hand it is a nice thing because Cantor can run different mathematical engines, in other hand it is very common developers create backends, release them with Cantor upstream, and forget this piece of software after some months. The consequence of this is a lot of unsolved bugs in Bugzilla, unexpected behaviours of some backends, and more.

For instance, R backend is broken from some years right now (thanks Rishabh it was fixed during his GSoC/KDE Edu Sprint 2017 but not released yet). Sage backend breaks for each new release of Sage.

Different backends use different technologies. Scilab and Octave backends use QProcess + Standard Streams; Python 2 uses Python/C API; Python 3, R, and Julia use D-Bus.

In addition to these, remember each programming language used as mathematical engine for Cantor has their respective release schedule and it is very common new versions break the way as backends are implemented.

So, yes, the mainternhip of Cantor is a hell.

In order to remedy it I invited developers to be co-maintainer of these respective backends, but it does not have the effect I was suposed to. I implemented a way to present the versions of programming languages supported in the backend but it does not work well too.

So, my main work in Cantor during these years was try to solve bugs of backends I don’t use and, sometimes, I don’t know how they work, while new features were impossible to be planned and implemented.

If we give a look to Jupyter, the main software for notebook-based mathematical computation, it is possible to see this software supports several programming languages. But, in fact, this support is provide by the community – Jupyter focus effort in Python support only (named the ipython kernel) and in new features for Jupyter itself.

So, I would like to hear the KDE and Cantor community about the future of Cantor. My proposal is split the code of the others backends and put them as third-party plugins, maintained by their respective community. Only the Python 3 backend would be “officially” maintaned and delivered in KDE Applications bundle.

This way I could focus in provide new features and I could to say “well, this bug with X backend must be reported to the X backend community because they are accountable for this piece of software”.

So, what do you think about?



Sprint do KDE Edu 2017

16 de Dezembro de 2017, 19:32, por Filipe Saraiva's blog - 0sem comentários ainda

Dois meses atrás participei do sprint do KDE Edu em Berlim. Essa foi a primeira vez que participei de um sprint do KDE (pois é, sou contribuidor do KDE desde 2010 e nunca tinha ido a um sprint!) e por conta disso estava bastante animado com o que iria encontrar.

KDE Edu é um guarda-chuva específico para softwares educativos do KDE. O projeto tem um monte deles, e essa é a principal suíte de softwares educativos no mundo do software livre. Apesar disso, o KDE Edu tem recebido pouca atenção no quesito organização. Um exemplo são os próprios sprints: o último ocorreu há muitos anos atrás, o website do projeto está com alguns bugs, entre outros problemas.

Portanto, esse sprint não foi apenas uma oportunidade para trabalhos de desenvolvimento (o que se espera desse tipo de encontro), mas também um bom momento para muito trabalho na parte de organização do projeto.

Nesse aspecto, discutimos sobre o rebranding de alguns dos softwares mais relacionados com trabalho universitário do que com a “educação” em si, como o Cantor ou o Labplot. Há um desejo de se criar algo como um KDE Research/Science de forma a colocar todos esses softwares e outros como o Kile e KBibTex sob um mesmo guarda-chuva. Há uma discussão sobre esse tema em andamento.

Outro tópico também discutido foi um novo site, mais direcionado a ensinar como utilizar softwares do KDE no contexto educacional do que apenas apresentar uma lista de softwares. Acredito que precisamos implementar essa ideia até para termos uma entrada própria na página de produtos do KDE.

Em seguida, os desenvolvedores do sprint concordaram com a política de multi-sistemas operacionais para o KDE Edu. Softwares do KDE podem ser compilados e distribuídos para usuários de diferentes sistemas operacionais, não apenas Linux. Durante o sprint, alguns desenvolvedores trabalharam no desenvolvimento de instaladores para Windows, Mac OS, no port de aplicações para Android, e mesmo na criação de instaladores independentes para qualquer distribuição Linux usando flatpak.

Ainda relacionado aos trabalhos organizativos, criei uma regra para enviar e-mails para a lista de e-mails do KDE Edu para cada novo Differential Revision nos softwares do projeto no Phabricator. Desculpem devs, nossas caixas de e-mail estão cheias por minha culpa. 🙂

Já nos trabalhos relacionados a desenvolvimento, foquei-me em trabalhar pesado no Cantor. Primeiro, fiz alguns trabalhos de triagem de tarefas na workboard, fechando, abrindo, e colocando mais informações em algumas delas. Em seguida, revisei alguns trabalhos feitos por Rishabh Gupta, meu estudante durante o GSoC 2017. Ele portou o backend de Lua e R para QProcess, que estarão disponíveis logo mais.

Após isso trabalhei no port do backend de Python 3 para usar a API Python/C. Esse é um trabalho em andamento e espero finalizá-lo para lançamento com a versão 18.04.

E claro, além desse monte de trabalho nos divertimos com cervejas e comidas alemãs (e alguma comida americana, chinesa, árabe, e italiana também). Algo legal foi ter completado meus 31 anos no primeiro dia do sprint, portanto obrigado KDE por ter vindo à minha festa repleta de código-fonte, boas cervejas e pratos de comida com carne de porco. 🙂

Finalizando, é sempre um prazer encontrar outros  gearheads como os amigos espanhóis Albert e Aleix, o único outro usuário Mageia que já encontrei pessoalmente em minha vida Timothée, meu aluno do GSoC Rishabh, meu camarada Sandro, e os novos amigos Sanjiban e David.

Obrigado KDE e.V por fornecer os recursos necessários para que o sprint acontecesse e valeu Endocode por sediar o evento.



Análise das fórmulas para votação na consulta do ICEN-UFPA

15 de Dezembro de 2017, 15:50, por Filipe Saraiva's blog - 0sem comentários ainda

Esse post tem como finalidade fazer uma análise da fórmula utilizada para a consulta da direção do Instituto de Ciências Exatas e Naturais (ICEN) da UFPA. O objetivo é mostrar como uma mesma fórmula pode levar a diferentes situações a depender do cenário onde ela é aplicada.

A seguir utilizaremos algumas siglas cuja legenda é a seguinte:

P    = Pontos obtidos pela chapa;
VD = Votos dos docentes;
VT  = Votos dos técnicos;
VA  = Votos dos alunos;
UD  = Universo de docentes;
UT   = Universo de técnicos;
UA  = Universo de alunos.

É costume nas eleições do ICEN se utilizar da chamada “fórmula paritária”, muito utilizada em universidades Brasil afora e, no contexto da UFPA, também na consulta para a reitoria. A fórmula é a seguinte:

P = 1/3 * [(VD/UD) + (VT/UT) + (VA/UA)]

Nessa fórmula, cada segmento da universidade (docentes, técnicos e alunos) tem o mesmo peso na votação. A fórmula acaba por dividir, dos 100% de votos disputáveis, 33,333…% para cada segmento. Como o peso de cada segmento como um todo é o mesmo, esse valor acaba sendo diluído pela quantidade de membros dos segmentos a fim de calcular qual o peso do voto único de cada eleitor na consulta.

Essa é uma boa fórmula na medida em que a quantidade dos membros de cada seguimento for também relativamente equilibrado. Utilizando por exemplo os números dos segmentos da UFPA: segundo a apresentação UFPA 2017 em Números – Ano Base 2016, a instituição conta atualmente com 40.310 alunos matriculados na graduação e 9.125 alunos na pós-graduação, totalizando 49.435 alunos. O número de professores é 2.631 (magistério superior + educação básica/profissional) e o de técnicos 2.541.

Nesse cenário temos que o voto de um professor equivale aos votos de 18,79 estudantes. Essa situação indica o seguinte: apesar de matematicamente cada segmento brigar por uma fatia de 33,333…% do total de votos, no final serão necessários 18,79 estudantes para igualar o voto de um único professor. Fazendo uma análise em termos políticos, é bem mais fácil convencer 1 pessoa a votar em algo do que 18. Infelizmente é muito complicado equilibrar o voto dos estudantes com os dos demais segmentos no contexto universitário, afinal o número de estudantes sempre será muito maior que o de docentes e técnicos.

Ainda nesse cenário, o voto de um técnico equivale aos votos de 1,03 professores. Isso reflete o número relativamente equilibrado de técnicos e docentes da instituição. Como não existe 0,03 voto, esse valor só representará algo (ou seja, expressará 1 voto completo) quando a diferença de votos entre técnicos e docentes estiver na proporção de 34 votos de diferença (1,03 * 34 = 35,02), o que é uma proporção razoável.

Ou seja, a fórmula paritária permite uma disputa equilibrada de votos nos segmentos de professores e técnicos pois o cenário da UFPA como um todo é equilibrado para esses dois grupos. Isso é completamente diferente para o caso do ICEN.

Segundo dados que circularam em reuniões da congregação do instituto, o ICEN tem hoje 160 professores e 50 técnicos, fazendo com que o número daqueles seja mais que 3 vezes maior que o destes.

Por conta desse desequilíbrio, em termos de votação, o voto de 1 técnico equivale ao voto de 3,2 professores. Novamente, por mais que cada grupo dispute uma fatia de 33,333…% dos votos totais, é mais simples convencer 1 pessoa a votar em algo do que 3,2. E temos que lembrar que esses números escalam: igualar o voto de 10 técnicos necessitará de 32 professores.

Essa situação tem diversos efeitos negativos, e não apenas para os professores que tem menos força decisória sobre a consulta. Os técnicos, por terem mais peso nos votos, estão potencialmente sujeitos a todo tipo de pressão.

Diante dessa situação, a Faculdade de Computação propôs uma nova fórmula para a consulta do ICEN, que é a seguinte:

P = 2/3 * [(VD + VT) / (UD + UT)] + 1/3 * (VA/UA)

O que essa fórmula faz é unir as categorias docentes + técnicos (chamando essa união de “servidores”), e atribui a ela o peso de 2/3. Nesse cenário, o voto do docente e do técnico não serão diferentes, tendo ambos o mesmo peso 1. Será voto universal específico para esses dois segmentos, disputando 66,666…% dos votos totais.

Dessa forma, resolvemos o desequilíbrio que existe entre os 2 segmentos para o ICEN e eliminamos os efeitos colaterais negativos também para ambos os grupos que a fórmula paritária gera nesse cenário.

No momento as duas fórmulas estão em votação na congregação do instituto e logo saberemos qual delas será a utilizada no certame.