A Fábrica Livre

Apesar do sistema de release do KDE ter sido implementado há mais de um ano parece que não foi bem assimilado em alguns aspectos importantes e este fim de semana encontrei comentários meio despropositados como por exemplo reclamarem da instabilidade do KDE e usando como exemplo ter saído dois pacotes de bugfix em dois meses.

O release do KDE SC tem um sistema de três números, que vamos chamar de X.Y.Z. X é a versão principal. Uma mudança em X indica uma grande mudança na arquitetura e graves incompatibilidades com outra versão. A versão atual é 4 e deve permanecer assim por um bom tempo. Y é o release incremental que adiciona funcionalidades e recursos e Z o release de estabilização e tradução.

Portanto o KDE SC 4.4.2 que estou usando é o segundo bugfix da versão 4.4. Desde que conheço o projeto KDE ele utiliza este sistema de numeração de versões, o que mudou de uns tempos para cá é a regularidade. O projeto definiu que os releases Y são semestrais e os releases Z são mensais. O calendário do KDE SC passa então a ser parecido com o calendário do GNOME, com novidades a cada seis meses. A diferença é que enquanto o GNOME lança apenas uma versão a cada seis meses, devidamente estabilizada, o KDE lança 6, em um processo paulatino de estabilização.

A 4.Y.0 é a versão inicial com novos recursos e funcionalidades e passará por um processo de estabilização de seis meses. Portanto a versão 4.Y.5 é a mais polida, estável e com as traduções mais completas. O que não quer dizer que a 4.Y.0 seja um beta ou algo assim. Ela já passou por um processo interno de estabilização, teve alfas, betas e RCs. Você não encontrará grandes problemas em usar essa versão. Mas se você quer uma versão do KDE SC estável para uma distribuição LTS ou se simplesmente se irrita com pequenos bugs, use sempre a versão 4.Y.5 que é a mais estável.

Espero que ajude os usuários a entender o ciclo de desenvolvimento do projeto, para que não reclamem dos bugfixes mensais ou de eventuais inconsistências nas versões X.Y.0.

=-=-=-=-=
Powered by Blogilo

Originalmente publicado em 30 de junho de 2009

É interessante fazer essa pergunta em um momento de revitalização do projeto como esse. O KDE ganha (e reconquista) adeptos com sua versão 4.2.X excelente e provavelmente continuará seu ciclo virtuoso com a 4.3.X e assim por diante.
Mas existem dois fatores importantes para avaliar o futuro do KDE.

1. Licenciamento do QT em LGPL.
   Com essa medida desenvolvedores foram atraídos já que o framework pode ser usado para projetos comerciais.
2. Riqueza do framework QT a partir da versão 4
   Antigamente se via uma diferença clara de qualidade entre aplicativos QT e aplicativos KDE. O QT era muito mais pobre e limitado. Atualmente não mais

Antes era incomum encontrar aplicações ricas em recursos e agradáveis ao olhar escritas em QT, hoje a situação começa a mudar. Aplicações KDE ainda são via de regra mais poderosas que as QT, mas podemos classificar o poder as aplicações KDE4 como overkill. Plasma, geolocalização, solid, composição, nepomuk, etc são mais do que se espera de um ambiente desktop, mais do que se espera de uma aplicação. O KDE 4 está abrindo fronteiras e desbravando terrenos, o QT é mais tradicional, mas não passa mais a imagem de pobreza. A prória aparência do QT é mais agradável agora uma vez que temas KDE como o Bespin ou Oxygen são também temas do QT.
Procurando aplicações QT puras encontramos por exemplo o Cuberok, que não consegue competir com o Amarok2, mas está no páreo de Exile, Listen e Amarok 1.4.
Se o Konversation ainda não deu as caras, apareceu o Quassel que em nada fica devendo.
Na falta de plasmoids simplesmente se cria uma nova engine de gadgets, a Kludget.
Sem uma solução de PIM integrada como o Kontact/Akonadi, mas com um programinha legal chamado qOrganizer. Um cliente único de download para http, ftp, torrent, rapidshare, youtube, etc, o Fatrat.
Todos nós conhecemos o Psi, talvez até o qTwitter, mas de projetos ambiciosos como o qxhtmledit, que me pareceu um editor web wysiwyg mais competente que o Komposer/NVU até coisas simples e lindas como o Picturewall que permite navegação visual das imagens do computador.
Sem contar projetos antigos e razoavelmente desconhecidos como o Mantools (Mandvd, Manslide e Manencode) que é a melhor opção para iniciantes na área de projetos de vídeo caseiros e MyMediaPlayer que me pareceu bem mais leve que o Elisa quando instalei.
E pra completar, a cereja do bolo, Antico, um gerenciador de janelas QT em fase inicial de desenvolvimento e Arora, um browser que usa a engine do webkit.

Mas essa lista toda tem que ter um motivo…
Bem o motivo é falar que o QT está ganhando importância diante do KDE. Uma importância que antes não tinha. Uma aplicação QT é menos integrada, mas exatamente por isso mais fácil de distribuir. os 30 MB do framework QT e todas elas funcionam. Enquanto uma KDE vai precisar de uns 300 só apra as dependências.
Assim como aplicações GTK há algum tempo atrás tomaram de assalto outras plataformas como por exemplo GIMP e Firefox, podemos ver esse movimento com o QT no futuro. Já é praticamente possível construir uma distribuição baseada em aplicativos QT. Quase todos ainda novos e carecendo de maturidade, mas bastante usavies e funcionais.
O futuro do KDE provavelmente vai ser continuar na vanguarda inovando e garantindo o direito de se chamar de “most powerful desktop enviroment”. É claro contribuindo para o framework QT, como por exemplo foi o phonon que foi assimilado depois de ser criado no KDE.
O que fica cada vez mais claro para mim é que cada vez mais desenvolvedores vão potar por manter suas aplicações usando apenas as biblioteas QT, e as aplicações KDE vão cada vez mais se resumir às oficiais (ou semi oficiais), ao contrário do que ocorria anteriormente.
Não que isso seja ruim para o usuário do KDE, já que as aplicações QT se integram perfeitamente ao ambiente.
E de modo algum para o próprio KDE.
Garante aplicativos de terceiros integrados ao sistema e programadores com conhecimento sobre a base de sua API.
Naturalmente em termos de marketing também é uma boa um crescimento das aplicações QT.
É apenas o começo. Vejamos no que que dá.

Se isto não for algo inédito me avisem, porque por enquanto estou acreditando que é.

Ontem, seis de novembro ele recebeu a Cruz do Mérito da Alemanha por sua contribuição com o software livre em reconhecimento a seu trabalho incentivando a inovação e e distribuindo conhecimento para o bem comum.

Matthias fundador do projeto KDE em 1996 é a pessoa mais jovem a receber a medalha, que é a mais importante da Alemanha, bem como a única de caráter geral. No Brasil seria algo equivalente à ordem do cruzeiro do Sul

O KDE é provavelmente o maior projeto de softwre livre organizado no modelo de bazar, onde todas as questões são resolvidas por consenso e mais raramente, votações.

É uma ocasião histórica, que deve ser comemorada pelo movimento do software livre em que o seu esforço é reconhecido pelo poder públicode uma forma até onde eu vi, inédita.

Referência: http://dot.kde.org/2009/11/06/matthias-ettrich-receives-german-federal-cross-merit

=-=-=-=-=
Powered by Bilbo Blogger

Este é um post que foi originalmente escrito em 6 de julho. Estou republicando aqui porque ele não está mais no local original e preciso fazer referência a ele.

Comentários adicionados o serão feitos em vermelho

Espero quase nada.
Não que eu esteja falando mal do ambiente. Tenho plena consciência de que meu é apenas gosto.
O problema é que o Gnome não tem claro para si o que pretende fazer. Resolveu implementar esse tal de 3.0 apenas porque o KDE lançou a 4.x. Concorrência é saudável, mas uma evolução orgânica é mais ainda. Faltou organicidade. Tanto é que apenas meses depois do anúncio de que a 3.0 seria a 2.30 começou a se ter uma noção do que esse novo ciclo seria.
Tenho muitas dúvidas de se o pacote prometido vai chegar a tempo inclusive. O KDE 4 foi movido para trunk do SVN em agosto de 2005. Passou a ser tratado como versão de desenvolvimento. O primeiro alpha só saiu em maio de 2007, para finalmente a versão 4.0.0 ser lançada em janeiro de 2008. Só agora, em agosto de 2009 será lançada a versão 4.3 que pode ser considerada mais completa e polida que a última versão da série 3, a 3.5.10.
O Gnome 2.26 foi lançado em março, ainda sem nada realmente revolucionário. Tem mais 3 meses antes do próximo release e depois disso só mais seis meses para concretizar a promessa de uma revolução na experiência de usar o computador.
É claro que a mudança do Gnome será muito menos drástica que a do KDE que desenvolveu uma série de recursos e infra estruturas, enquanto o Gnome basicamente mudará apenas sua aparẽncia mantendo sua infra estrutura inalterada.
Mesmo assim, considero pouco tempo para a promessa.

Mentira isso. O Gnome fez um bom trabalho combatendo a redundância de bibliotecas que ele tinha e a introspecçaõ Gobject é uma modificação de infra estrutura que ainda não estudei para decidir se gostei

Talvez não para mudar o gerenciador de arquivos e o gerenciador de janelas, o que parece que vai ser. O KDE fala de geolocalização, de ambientes funcionais, de integração de informações entre aplicativos. De ambiente semântico, diretórios virtuais, etc.
O Gnome está apresentado mockups horrendos sobre você precisar de muito mais trabalho que o normal para alternar entre ambientes e nada que um bom compiz não faça de forma mais elegante (e que o KDE faz nativamente)
Sinceramente os planos de 3.0 não me impressionam. O resultado mostrado até agora é muito pouco para algo com um lançamento iminente. Si tivesse que fazer uma aposta seria simplesmente que o Gnome 3.0 ou não vai estar pronto ou vai ser lançado sem estar.
O KDE 4.0.0 foi uma decepção para muita gente. Imagino que o Gnome 3.0 vá ser uma maior. Resta saber se a equipe Gnome vai ter a clareza de como o time KDE manter a versão anterior atualizada.
Afinal, em agosto de 2005 quando o KDE4 foi movido para o trunk o KDE estava na versão 3.4.2. Depois disso tivemos a 3.4.3 e a 3.5 da zero até a dez.

=-=-=-=-=
Powered by Bilbo Blogger

O Konqueror, navegador padrão do KDE é uma pequena contradição. Deu origem ao webkit mas nunca o adotou. Sua engine mais “alternativa”, a KHTML é incompatível com uma série de sites, incluindo o Gmail, o que fez com que eu nunca o usasse por mais que alguns minutos de necessidade. Sua rapidez é temperada com bugs e é um navegador que realmente, não conheço alguém que diga que o usa como navegador principal.

O Conquistador perdeu terreno há tempos.

Existe um projeto, chamado Rekonq, ou Reconquistador. Talvez o objetivo seja reconquistar o espaço perdido pelo irmão mais velho. Talvez.

Instalei pelo AUR do Arch Linux a versão 0.2.92, que é um beta para a 0.3. Instalação rápida e sem problemas.

Seu design é baseado no do Chrome e sua engine é o WebKit, do Chrome e do Safari. Porém sua versão é mais atualizada que a presente no Chrome, o que melhora sua compatibilidade com alguns sites, que comigo só funcionam bem com Arora e Rekonq. Ironicamente ele se sai pior no teste Acid3 (ambos falham).

Sua página inicial apresenta um speedial que me parece feito com plasmoids e dentro dela temos várias abas, incluindo favoritos, abas fechadas recentemente, e histórico. As abas fechadas recentemente tem miniaturas também, como o speedial, infelizmente carregadas quando a página é aberta, fazendo com que tenhamos que esperar um bom tempo até poder ver as miniaturas. Aliás, um bug que reportei ao desenvolvedor. Os favoritos não tem miniaturas nem há um editor ou maneira de apagar favoritos ainda.

Ou seja, uma versão de desenvolvimento ainda não pronta para uso. Mas tenho que admitir que por mais que tenha tentado, não consegui nem quebrar o navegador nem fazê-lo engolir toda a memória livre do sistema. Ele trabalha muito bem com o flash, é rápido, leve e compatível com boa parte dos sites. É um projeto para se ficar de olho. Principalmente que o Qt e o KDE, com a integração de aplicação e webkit, plasmoids dentro de aplicativos, QtScript… Existe um grande espaço para construção de extensões e plugins, assim como por exemplo o Amarok.

Site do projeto

Blog do desenvolvedor princicpal

=-=-=-=-=
Powered by Bilbo Blogger

Recentemente migrei para o Arch Linux 64 bits.

Curiosamente foi também a primeira vez que deixei a preocupação com a segurança de lado e usei o yaourt. Esse artigo dá uma visão geral da instalação, ferramentas e etc.

Não é um tutorial para iniciantes. Mas sim impressões sobre o sistema voltados para outros usuários do sistema.

Sistema Base

Como sempre nada foi configurado para mim. Esqueci de iniciar o Hal antes de iniciar o X pela primeira vez e tive que rebotar pelo botão. O X.org atual reconhece teclado e mouse a partir do hal, portanto sem iniciar esse serviço é impossível sair de um ambiente gráfico travado.

Dica:

Quem inicia o gerenciador de login como daemon no rc.conf pode ter que editar o arquivo via livecd ou outra distribuição. É por isso, por exemplo, que se recomenda usar o inittab

Atualmente carrego no boot apenas os daemons syslog-ng network alsa dbus e hal, o que me garante um sistema rápido e eficiente.

A arquitetura i686 dá um ganho sensível de eficiência e velocidade em relação à i386 do Debian/Ubuntu, mas não há um ganho tão grande em relação a distribuições que usam i586 como Mandriva ou SUSE. Porém do i686 para x86_64 existe um ganho palpável. Não mensurável objetivamente. Mas percebe-se que o sistema fica mais fluido.

Os tais registradores de 64 bits ao que parece são usados para aplicações com grande fluxo de dados como gráficos e multimídia gerando um desafogamento do processador.

Tive problemas para configurar o layout de teclado no novo X.org como muita gente e com a geração de locales

Dica:

Além de definir os locales no rc.conf é preciso descomentar suas linhas no arquivo /etc/locale.gen e depois rodar como root locale-gen para que tudo funcione bem.

Ferramentas:

Pacman e repositórios.

O pacman é ótimo. Mas nem tanto. É preciso se acostumar com suas opções e memorizar coisas como pacman -Scc para limpar o cache.

Um exemplo claro de falha na resolução de dependências desencotradas é que logo depois da instalação ele aponta que o pacote linux-util-ng conflita com o e2fsprogs e que este será removido. Qualquer um que saiba algo sobre esse último se recusa a removê-lo. O problema se resolve facilmente atualizando o e2fsprogs, que curiosamente exige a atualização do linux-util-ng (vai entender).

às vezes tenho a impressão de que estou instalando coisa demais e me dá vontade de usar Gentoo e poder instalar o KDE sem instalar o samba ou o mysql, mas lembro da dor de cabeça que é atualizar um Gentoo e desisto.

Os repositórios são pequenos e não tem tudo que você imaginar. E nem precisam. O sistema te incentiva a construir PKGBUILDS e instalar através do source com o controle de dependências do pacman. Mas sinto falta de mais clareza quanto a onde está o tutorial para fazer PKGBUILDS na wiki do projeto.

O AUR tem praticamente de tudo. Os mais atualizados, sombrios e marginais pacotes podem ser achados lá. Inclusive coisas altamente instáveis e experimentais.

Encontrei lá plasmoids que não ia achar em lugar mais nenhum do universo. O snapshoot do Google Chrome, as versões svn com recursos novos de programas que eu uso como o choqok e versões com flags de compilação que desabilitam funções incomuns ou menos úteis, etc.

Mas há um defeito. A maior parte dos PKGBUILDS do AUR não funciona de primeira sem o yaourt. Eles tem uma parte do código que não funciona com um simples makepkg.

Por outro lado o yaourt é um excelente programa que unifica a instalação de aplicativos, já que ele instala programas tanto no AUR quanto nos repositórios. E ele pode ser rodado como usuário comum te perguntando a senha do root apenas na hora de instalar o pacote.

É trabalhoso instalar pacotes pelo AUR quando eles dependem de outros pacotes do AUR. O yaourt resolve isso, mas é cansativo ler os scripts de cada uma das dependências. Mas menos, muito menos que baixar os PKGBUILDS, e editá-los para que funcionem sem o yaourt.

Rodando o sistema padrão (KDE 4 com composição via kwin, amarok tocando música, Chrome com umas dez abas abertas, Bilbo blogger aberto bem como Choqok e compilando o gimp em segundo plano) uso 860M de memoria e 100% de processador, mas sem engasgos e com tudo fluido.

Meu processador é um Celeron 1600 Mhz EMT64 de um único núcleo. por experiência própria, em i686 tenho que escolher entre compilar um código e ouvir música.

=-=-=-=-=
Powered by Bilbo Blogger

Mesmo tendo instalado o Gears no WordPress ainda me parece uma perda de tempo acessar o site. A localização de rascunhos não é a coisa mais simples do mundo e a formatação e correção rotográfica é pouco responsiva em comparação com um programa normal.

Então procurei um bom cliente de blog. como podem ver pelo tema do site uso KDE, portanto a escolha natural é algum em QT ou KDE. E encontrei o Bilbo Blogger, ou melhor Blogilo, como passou a se chamar há tão pouco tempo que a minha barra de título ainda está com o nome do hobbit escrito nela.

Consegui configurar facilmente os blogs através do seu domínio, usuário, senha e um maravilhoso botão “Auto Configure” que faz todo o trabalho sozinho.

Ele armazena os arquivos de cada blog separadamente, e dá acesso a rascunhos que estejam no servidor e a posts já publicados. Para se escolher o blog a ser trabalhado se usa um drop down no topo da tela. Permite publicar o post no servidor ou colocá-lo como rascunho.

Mas falemos do defeitos, já que são tão importantes quanto a rapidez, praticidade e eficiência do mesmo.

Ele não faz upload de imagens no Blogger e não permite redimensionar as imagens manualmente depois de inseridas. Só digitando-se o tamanho ao inseri-la ou pelo código HTML.

Além disso não é capaz de criar categorias, o que vai me obrigar a entrar no WordPress, criar uma categoria e só então postar essa mensagem. Além disso não tem recursos para agendar posts, coisa que muita gente usa.

Apesar disso é através dele que pretendo blogar daqui por diante.