A Fábrica Livre

Tá, eu sei que melhoramentos não existe, mas gosto da palavra.

Todo o conteúdo deste post foi postado no openFATE.

E você? Que melhoramentos sugere?

1. Usabilidade do Yast-pkg
   1. Depois de instalar um pacote o gerenciador de pacotes fecha. E se eu quiser instalar outros? tenho que abrir de novo, esperar carregar, etc.  https://features.opensuse.org/310285
   2. Se eu pesquiso por duas palavras ele procura pela expressão formada pelas duas, não por qualquer conjunto das duas. Se por exemplo, quero um cliente twitter em Qt não posso escrever “twitter qt” porque ele vai pesquisar a expressão, como se eu tivesse escrito ” “twitter qt” “. https://features.opensuse.org/310288
   3. Após instalar um pacote, qualquer que seja, o Yast roda todos os scripts de configuração. Muitos deles fazem uso intensivo de CPU e demoram um bocado para acabarem. Se estou instalando um jogo SDL não vejo necessidade de rodar o script de configuração do texlive ou do GTK. https://features.opensuse.org/310289
   4. Não há uma maneira fácil de atualizar os repositórios manualmente. Ou eu configuro atualização automática e tenho que esperar atualizar todos os repositórios antes de começar a instalar ou remover os programas ou tenho que ir a o módulo dos repositórios e pedir a atualização dos repositórios habilitados, esperar terminar e só então ir para o módulo de gerenciar pacotes.  https://features.opensuse.org/310286
2. Ambiente KDE
   1. O menu é muito subcategorizado. Isso é bom para separar os aplicativos, mas considerando que são necessário três cliques para iniciar qualquer  um é um saco. Enquanto em outras distribuições os programas estão logo após a categoria no suse estão dentro de subcategorias nem sempre bem definidas. Por exemplo, o SMplayer está dentro de Reprodutores de audio, mas eu uso programas com suporte a coleções para reproduzir áudio e o SMplayer para vídeo por causa do suporte a legendas mais robusto. https://features.opensuse.org/310291
   2. Não tem pacotes, nem sequer experimentais para os recursos avançados do Nepomuk, como o Scribo. https://features.opensuse.org/310290

O assunto é velho, mas é um dos que eu gosto. Saiu hoje no Br-Linux uma matéria sobre como o excesso de distribuições prejudica o Linux e nos inúmeros comentários surgiu uma discussão correlata, sobre a falta de padronização. Como já falei tudo que tinha para falar sobre o “excesso” de distribuições vou me ater a discussão sobre padronização.

Mito 1 – É preciso um sistema de empacotamento único

Na verdade não. Já usei rpm (3 sabores), deb (2 sabores), tgz e hoje uso pkg.tar.xz e devo ter esquecido um ou dois tipos de pacotes. Os pacotes contém arquivos binários compilados dinamicamente e arquivos de configuração que definem as suas dependências e eventuais scripts de configuração.

Os binários rodam em qualquer distribuição Linux que atenda às dependências e seja da mesma arquitetura. Nisso aliás se baseia o alien que converte rpm e deb.

Aliás, muitas bibliotecas mantém compatibilidade binária com versões anteriores fazendo com que um pacote construído com uma versão antrior continue funcionando na nova. Nada me impede de descompactar um pacote deb feito para o Ubuntu e usar os binários no meu Arch Linux atual.

Os arquivos de configuração podem ser facilmente convertidos de um sistema de pacotes para outro por scripts automáticos. Os scripts de configuração, exceto em pacotes básicos de sistema também costumam funcionar em qualquer distribuição com nenhuma alteração ou alterações mínimas.

O único padrão realmente necessário é na árvore de diretórios. É a falta de padronização na árvore de diretórios que impede a existência de pacotes universais ou facilmente conversíveis, não a existência de vários padrões de empacotamento.

Um padrão sobre diretórios para servidores, serviços e bibliotecas adotado por todas as distribuições permitiria que um programa precisasse ser compilado uma vez para cada arquitetura  e empacotado quantas vezes se quiser. É claro que um programa compilado em um Arch atualizado vai resultar em um pacote incompatível com um Debian stable de um ano atrás, mas isto são pontos fora da média. Boa parte das distribuições sofre grandes atualizações a cada seis meses, o que é um delay aceitável.

Quanto ao aprendizado de uso do gerenciador de pacotes em si, que atire a primeira pedra o “usuário comum” que gerencia pacotes via linha de comando. Todas as principais distros tem GUIs muito boas para isso há pelo menos dez anos. GUIs auto explicativas.

Mito 2 – É preciso uma API oficial

Bem, se fosse assim estaríamos até hoje com sistemas péssimos. Particularmente acho que o trabalho necessário para fazer o toolkit Motif, que era padrão quando do lançamento do Linux, atingir a maturidade de um wxWindows, Qt ou GKT é muito maior que o necessário para criar esses toolkits. Isso para falar de toolkits. O HAL está sendo abandonado por ser uma base de código monolítica e de difícil manutenção em favor do DBus, o OSS foi abandonado por ter uma baixa qualidade a favor do ALSA que hoje em dia está perdendo terreno para o OSS4. Talvez no futuro vejamos o GCC deixar de ser o compilador padrão e o Clang assumir este posto.

Manter uma única API é limitar a evolução. Certas coisas não podem ser realizadas de modo incremental em APIs antigas. É preciso criar algo novo.

Alguns dos argumentos a favor de uma API única são facilitar a vida dos desenvolvedores. Bem, quem usa este argumento provavelmente não desenvolve para Linux, senão saberia que há várias camadas de abstração extremamente eficientes e produtivas. Queria saber quem, em 2010 escreve um player de música que use streams diretos para a placa de som através de ALSA ou OSS. Todos os projetos recentes que já vi usam GStreamer, Phonom, Pulse Audio ou outra API de alto nível que tornam a base irrelevante. Essas APIs de alto nível não precisam ser compatíveis entre si, já que é perfeitamente possível e funcional ter todas elas instaladas e rodando no mesmo computador e sua instalação é indolor em qualquer sistema que use um gerenciador de pacotes com controle de dependências.

Certamente os desenvolvedores tem um certo retrabalho já que temos várias APIs com funções razoavelmente parecidas, mas faz parte do processo de desenvolvimento. E todos que tenho visto reclamar do excesso de APIs NÃO programam APIs, mas apenas as usam, portanto não considero que essa reclamação tenha a devida propriedade.

Mito 3 – É preciso um ambiente gráfico padrão

Existe uma certa crença de que se houvesse apenas um ambiente gráfico este seria a sétima maravilha do mundo. No entanto o que percebo é os vários ambientes gráficos existentes tem objetivos irreconciliáveis e o desenvolvimento de um mega merge é absolutamente impossível e um projeto único iria ter tantas divergências internas que não se sustentaria a longo prazo.

A parte as flamewars sobre qual o melhor ambiente, temos hoje 5 grandes opções de ambientes desktop e dezenas de gerenciadores de janelas. XFCE, LXDE, Enlightment, GNOME e KDE tem objetivos e visões irreconciliáveis, visões diferentes de usabilidade e sobre quais recursos são fundamentais. Se baseiam em tecnologias diferentes que suportam recursos diferentes que tem objetivos diferentes.

Falando sobre o usuário e sua escolha entre 5 ambientes principais, tenho a dizer que todos eles são soluções razoavelmente maduras que vão ser boas o bastante para a grande maioria dos usuários, exceto talvez LXDE e Enlightment que curiosamente são os menos usados dos cinco. É importante também notar que o usuário não usa apenas um ambiente gráfico, mas uma distribuição que vem com um conjunto de aplicativos satisfatório para a maioria das atividades, portanto o tal do “usuário comum” vai instalar outro ambiente gráfico apenas se tiver curiosidade ou não estiver satisfeito com o padrão em um processo saudável de aprendizado.

Ao invés de várias dicas sobre o Gmail, vou dar apenas uma. Uma que mudou a minha vida e de outras pessoas que conheço.

Quem assina vários grupos de discussão como eu já deve ter sofrido com threads intermináveis que não lhe interessavam. Criar um filtro para cada thread é bem trabalhoso, criar filtros mais genéricos resulta em falsos positivos. No entanto, no menu "Mais ações" do Gmail existe uma opção chamada "Ignorar" (a tecla de atalho é "m", a quem interessar possa) que arquiva a thread e a mantém arquivada, mesmo chegando mais emails nela.

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

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

É grande o debate sobre distribuições adequadas ao desktop. Particularmente acho que as melhores são Mandriva, openSUSE e Arch, em grau crescente de nerdice.

Mundo

No entanto gastei algum tempo observando os dados de marketshare do Clicky. Não há como saber a confiabilidade. Ele diz que se baseia no tráfego de quase 180 mil sites em um total de mais de 100 milhões de pageviews diárias. As estatísticas são diárias, portanto flutuam bastante.
De 21 de setembro quando começam até hoje 2 de fevereiro (77dias) podemos ver um crescimento do linux, mas muito pequeno. Da casa de 0,45%.

Já no Linux podemos ver um domínio absoluto do Ununtu (e família) sobre as doutras distribuições em uma trajetória estável, seguido por distribuições sem identificação, em trajetória ascendente.

Brasil

No Brasil o Ubuntu caminha empatado com distribuições não identificadas. Há uma declinante base Debian e uma mínima e estável presença de Fedora e SUSE.
Uma sazonalidade interessante do Linux no brasil é que sua presença na internet cai sensivelmente nos finais de semana. Um chute admissível é que o uso do Linux no Brasil esteja muito ligado ao trabalho.

Alemanha

Na Alemanha o Linux tem uma honrosa e estável participação de aproximadamente 2,5% do mercado, tendo também o Ubuntu como lider absoluto e as distribuições sem identificação em segundo lugar isoladas bem a frente de Suse, Debian, Fedora e Gentoo.

Finlândia

O caso mais interessante. A presença do Linux estava estabilizada em 2,5% e nos dias 9 e 10 de janeiro cresceu subitamente e se mantém um pataar estável de 4% tendo chegado a picos de 4,5%. Possovelmente devido ao uso do do Clicky em algum site de grande movimento de Linux. Este crescimento é composto de Ubuntu e distibuições não identificadas com uma leve alta do Debian.

conclusões

O caso da Finlãndia me fez pensar… É virtualmente impossível dobrar a base instalada de micros Linux em dois dias. O Clicky mede pouco menos de 180 mil sites, a Net Applcations aproximadamente 40 mil. Em 2007 se estimava o número de sites da internet em 120 milhões.
Até que ponto essas méticas são confiáveis?
Pelo que eu aprndi de estatística a amostra é a parte mais iportante dos cálculos. Talvez se Google, Yahoo, Bing e Baidu relatassem quantos de seus visitantes tem qual sistema operacional teríamos uma estatística realmente confiável.
No entanto podemos sabr algumas coisas…
Todasas estatísticas disponíveis apontam para um predomínio do Ubuntu, um crescimento lento e uma presença na faixa dos 1,5% a 2%.

O Mandriva é uma distribuição linux poderosa, estável, leve e fácil de usar. Reconhece facilmente o hardware, durante a instalação se prontifica a remover os pacotes referentes ao hardware não usado com o intuito de deixar o sistema mais limpo.
O Mandriva tem um centro de controle unificado muito bem organizado e mais do que isso, muito completo e poderoso, ao mesmo tempo que simples de ser entendido por leigos. Nesse centro de controle ao acessar uma opção não instalada o sistema lhe avisa da necessidade de instalar programas e oferece a instalação na hora.
O assistente de configuração de rede é abrangente a ponto de perguntar se quer montar compartilhamentos SMB, criar um proxy e outras opções avançadas que ou ficam esparsas no painel de controle (SUSE) ou não existem (Ubuntu).
Não rodaria o Mandriva em um servidor, apesar do firewall com notificações no tray, mas com certeza é uma escolha melhor para o desktop que o Ubuntu que nessa versão veio com problemas nos driver de vídeo intel, numa anterior o som sumia ao atualizar o sistema, e assim por diante.
Os únicos problemas que tive no Mandriva instalado aqui foram causados por um módulo de memória defeituoso e já foram resolvidos.
Das grandes distribuições com certeza recomendaria para iniciantes o nosso amigo franco-brasileiro bem menos problemático que o derivado de Debian.
Só me espanta que as duas distribuições que mais se adéquam à migração de ambientes Windows são tão pouco conhecidas no Brasil. Mandriva para leigos e openSUSE para usuários avançados.
Mas se continuar vou acabar falando do SUSE e isso é assunto para outro dia.

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á.

Post originalmente publicado em 30 de junho de 2008 que ainda posso vir a precisar mandar para alguém

Enviei uns selos e etc, mas algumas pessoas tiveram dificuldade em adicionar os selos em seus respectivos blogs…

Por isso vou atender ao pedido do ditado popular e desenhar… um guia ilustrado de adicionar selos e botões em blogs do WordPress e Blogger.

Mas antes qual a diferença entre selo botão?…

À esquerda tem um botão da campanha Quixote de coração e alma. Ele tem um link que remete para uma página, assim como os botões das campanhas alí à direita.
Ainda à direita você tem um selo que recebi da Maíra do Paradoxalmente ser. Não tem link para lugar nenhum…
Um selo é um presente, uma condecoração, uma medalha… Um botão faz propaganda de um site e em o link para a sua origem… (Se bem se espalharem a bandeira de Quixote sm o link eu não me incomodo nem um pouco…)

WordPress

Vá na aba “Design” e dentro dela em “Complementos“:

Após isso encontra na coluna da esquerda um elemento de texto e adicione-o:

Dentro desse elemento que vai aparecer na coluna da direita coloque o código é é muito simples:

<a href=”LINK”><img src=”Endereço da imagem” width=”100%” /></a> Para botões e:

<img src=”Endereço da imagem” width=”100%” /> Para selos.

O Atributo width define a largura da imagem… você pode definir em pixels (100, 200, 756, etc.) ou em porcentagem. Se usar 100% ela vai ocupar a maio área possível dentro da coluna.

Depois de adicionada não se esqueça de salvar as alterações…

Após isso é necessário salvar as altrações de novo, mas dessa vez da página, e não do widget:

Ponto.

Blogger:

Escolha a opção “Layout” e escolha “Adicionar um Elemento de Página“:

Na janela que abre escolha “HTML/JavaScript” (Note que existe uma opção “Imagem” que é mais prática para selos e para imagens que você tenha no seu computador. Essa opção é a mais adequada para botões)

Na janela que vai abrir coloque o código é é muito simples:

<a href=”LINK”><img src=”Endereço da imagem” width=”100%” /></a> Para botões e:

<img src=”Endereço da imagem” width=”100%” /> Para selos.

O Atributo width define a largura da imagem… você pode definir em pixels (100, 200, 756, etc.) ou em porcentagem. Se usar 100% ela vai ocupar a maio área possível dentro da coluna.

Salve as alterações.

Pronto.

Post publicado originalmente em 6 de maio de 2008

Vamos lá que ainda não comentei esse novo lar. muito menos a maratona que foi necessária para fazer essa migração.

O Cacos de mim está hospedado no Sapo, que é um provedor português que usa como plataforma de blogging uma versão customizada do Live Journal. O problema é que ele não tem a ferramenta de exportação de conteúdo do Live Journal e quando eu entrei em contato com o servidor ele disseram que iriam me prover o arquivo, mas nunca entregaram.

Como já estava com quase duzentos posts, copiar manualmente não seria uma opção. Então toca a criar uma maneira.

A minha solução foi baseada em feeds RSS. Não fosse isso nada mais me restaria a não ser uma lenta, tediosa e repetitiva cópia manual.

Mas aí começam os problemas, porque  se simplesmente salvasse os feeds do blog teria apenas os últimos 25 posts. A minha sorte é que já há bastante tempo eu era assinante dos meus próprios feeds. E ainda bem que através do Google Reader, porque os leitores offline armazenam o conteúdo dos feeds em arquivos binários na maioria das vezes, e converter isso para XML  de novo depois é algo que não faria ideia de como fazer.

Mas bem… Como então fazer o download dos feeds armazenados no Google Reader? Não fazia ideia.

Horas de pesquisa e tentativas frustradas depois….

Descubro no Google Opreating Systen que é só usar a seguinte URL:

http://www.google.com/reader/atom/feed/URL_DO_FEED?r=n&n=NÚMERO_DE_ITENS

Beleza!

Consegui baixar todo o histórico do blog em um arquivo XML que pode ser importado para o WordPress, certo? Errado. Começando. Só o WordPress instalado em um servidor próprio importa RSS, não o blog obtido com o registro no WordPress.com

Mas isso é fácil de resolver. É só achar um servidor grátis com PHP e MySQL e instalar o WordPress. Exstem dezenas deles e dezenas de tutorias para instalar o WordPress. Não vou entrar em detalhes sobre isso.

Mas aí, mais um obstáculo, porque se tudo funcionasse não teria graça contar a história e eu faria apenas um tutorial.

O WordPress importa apenas feeds RSS, e o google produz Feeds ATOM. Qual a diferença entre eles? Várias, mas apenas no código. Para nós, pobres mortais que só queremos usar o produto é a mesma coisa.

E para mim que tinha todo o conteúdo em um arquivo que não conseguia importar para o WordPress, importava e muito.

Procurei maneiras de converter o arquivo ATOM para RSS. Não achei.

Hospedei o arquivo no servidor e procurei um serviço que convertesse feeds. Do Feedbuner a outros desconhecidos, nenhum funcionou (o FeedBurner, porque só trabalha com Feeds de até 500KB)

O único que fez o trabalho foi o atom2rss converter. Mas lembre-se. Você precisa hospedar o arquivo em algum lugar e depois indicar o link para ele.

Aí então, tudo certo.

No meu servidor gratuito consegui importa o arquivo que agora era RSS apenas para exportá-lo para um formato que o blog hospedado no WordPress.com pudesse importar. No caso a melhor opção é exportar como wodpress mesmo.

O que me deu outro arquivo XML com o mesmo conteúdo e diferença só no código.

Mas esse foi possível importa aqui no quixotesco.

Mas para que além de sair de um serviço obscuro de hospedagem sem ferramentas de migração serve esse tutorial?

Bem… por volta dessa época a Dai perdeu o conteúdo do blog dela que era do WordPress hospedado em um servidor próprio. E eu era assinamte do antigo blog dela também. Ao mesmo tempo que fazia isso com o meu conteúdo fiz com o dela. E já entreguei para ela o arquivo que ela pode importar no novo blog dela.

E posso afirmar com segurança depois de muito quebrar a cabeça tentando criar um método para fazer o que fiz que o Google Reader é uma excelente ferramenta de backup para blogs, ou outros sites que publiquem seu conteúdo em RSS. Que através desses passos é possível importar para o WordPress qualquer conteúdo que se tenha em RSS.

A comunidade brasileira de software livre é um tanto fechada (talvez até grosseira) quando aparece uma nova distribuição. Se essa distribuição for um reempacotamento então é quase melhor deixar de divulgar e portanto deixar de receber tantas críticas ferozes.
Se depender dos comentários que lemos pela internet, seria melhor se houvesse no máximo dez distros grandes e as pequenas simplesmente não fossem criadas.
Particularmente acho essa postura infantil, e argumento por argumento quero explicar esse ponto de vista.

1 – A diversidade de distros afasta o usuário iniciante.
Acho que a campanha do Mac que fala mal das versões do Windows faz mais efeito do que devia. A diversidade de distros na verdade garante que o usuário possa encontrar o seu sabor favorito, ou ter um sistema adequado às suas necessidades. Se é um iniciante sem conhecimento técnico para personalizar o sistema, conseguir um sistema já personalizado garante que ele vá ingressar no universo Linux. Neodizinha voltada para máquinas antigas, Dreamlinux, voltada para designers, Big Linux, Kurumin e Kalango, verdadeiras escolas ou soluções prontas.
A diversidade garante ao usuário a chance de encontrar uma distribuição que atenda às suas necessidades. Afirmar que as distros pequenas não deveriam existir é afirmar que as grandes atendem plenamente todos os usuários, o que sabemos que não é verdade. Não existe solução perfeita para todo mundo.

2 – O excesso de distribuição prejudica o desenvolvimento
Sempre aparecem os que dizem que é melhor contribuir para as grandes distros. No entanto, as grandes distros, por causa de seu tamanho precisam de mecanismos democráticos para assimilar novas funcionalidades, onde a contribuição do desenvolvedor pode simplesmente ser recusada. As pequenas distros são laboratórios para o desenvolvimento de tecnologias que no futuro podem ser adotadas globalmente. Ao incluir sua tecnologia em uma pequena distro onde há menos probabilidade de incompatibilidade com outros recursos e menos interferência externa sobre seu trabalho o desenvolvedor ganha liberdade para levar sua ideia adiante.
Exemplos de distros nacionais que desenvolvem tecnologias são Epidemic Linux, que tem um dos mais rápidos e eficientes instaladores livecd e módulos de configuração próprias integrados ao programa de configuração do KDE, unificando as opções di sistema com as específicas da distro e o Resulinux, que tem desenvolvido um trabalho muito interessante de aceleração de boot e controle de performance e prioridades do sistema para as distros derivadas de Debian.

3 – A maioria das distros criadas é inútil
Sim, existe um excesso de distros voltadas para uso geral e principiantes. Sim, concordo que maquiagens que apenas alteram tema não podem ou devem ser empacotadas como uma nova distribuição, mas afirmar que as distros são inúteis é dizer que as distros servem apenas para serem utilizadas.
As distros tem outras funções. Uma delas é pedagógica. A formação dos desenvolvedores. Com o aprendizado adquirido durante o desenvolvimento eles adquirem a capacidade de fazer cada vez mais. Outra é de propiciar um ambiente de desenvolvimento e teste para aquele recurso próprio desenvolvido pela distribuição. Outra fazer uma seleção de recursos e ferramentas para iniciantes e outra uma seleção para algum nicho específico do mercado.
As distros tem um objetivo objetivo, declarado em sua página, e outros mais subjetivos, mas ligados ao simples fato delas existirem.

No entanto, existe um ponto onde as distros brasileiras pecam e devem ser criticadas com razão. Na parte de compartilhar as suas soluções com a comunidade.
Num mundo ideal você não precisaria baixar e instalar uma distro para ter acesso ao código das soluções e programas exclusivos dela. Várias distros usam o kernel do Sidux, que é um excelente exemplo de distro pequena derivada de outras que desenvolve tecnologia, (não é bem tecnologia, mas a compilação feita pela equipe Sidux é tão boa que é bastante utilizada) mas facilita o acesso dessa tecnologia por outras pessoas.
Mas considerando a falta de apoio dessas distros, não espanta que elas tenham que se dedicar tanto à simples assistência dos usuário e desenvolvimento que quase não sobre tempo ou energia para separar e publicar o que elas tem de específico, contribuindo assim com a comunidade.
O que faz de uma distribuição grande ou pequena é apenas a adesão da comunidade. É por isso que SUSE, Mandriva e Fedora, que são excelentes distribuições tecnicamente tenham tão pouca força no Brasil. Porque o Brasil de Conectiva a Kurumim sempre se usou apt. Porque o boom do linux nacional aconteceu com livecd Debian based no rastro do Kurumim que por causa da desatualização dos repositórios Debian migrou para Ubuntu, onde as pessoas descobriram que é mais fácil usar uma grande distro com fóruns de suporte grandes e cara mais profissionais que investir na GPL.
A liberdade de criar, alterar e redistribuir código é difícil. É muito mais cômodo adotar a postura de consumidor que apenas espera que a empresa lance a nova versão do produto que participar de um fórum pequeno reportando bugs de uma distro pequena e respondendo dúvidas primárias de usuários primários. E quando aparece uma nova distro simplesmente falar que é perda de tempo, apenas porque estamos satisfeitos sendo simples consumidores das grandes distros.