Pra ser sincero eu também gostaria de uma distro rolling release ao estilo do fedora. Ultimamente, tenho ficado muito mais no Arch do que no fedora e posso dizer que a ideia de um rolling release, mesmo com suas consequências -- que não são lá muito drásticas do jeito que falam -- é perfeita para a maior parte dos usuários. Esse negócio de ter de se preocupar em formatar a máquina para passar para a próxima versão vai ficando chata com o tempo e também parei de curtir. Tanto é que até o presente momento eu não atualizei o meu fedora para a versão 16.

Mas uma coisa eu discordo de você. Quando disse que uma distro não atualizaria do GNOME 2 para o 3 e seguindo esse tipo de ideia, eu me perguntei: Mas quando então ela o faria, afinal? Em algum momento terá de acontecer alguma descontinuidade na experiência do usuário justamente pelo fato de termos algo completamente diferente. A mudanção do GNOME 2 para o 3 -- ou qualquer outro software/ambiente -- ocorre de maneira bastante descontínua muitas vezes e não há muita coisa que uma distro rolling release poderá fazer a respeito. Até porque, o problema não é com ela e sim que o upstream que assim o desejou.

Henrique, você consegue acessar ele do Linux? Aqui diz que não há um cliente para Linux.

Bom, se for gratuito como você citou no início, me mande um também que irei experimentar. Tu tem meu e-mail, não?

Abraçõs.

Quando o pacman se oferece para importar a chave, ele o faz, mas sem assinar ela. Depois dessa importação, é necessário que o usuário uso o comando pacman-key com a opção --lsign-key ou não vai rolar. Fiquei alguns minutos perdido nessa parte por causa disso. Daí o blog do Allan esclareceu bem. =]

Já faz alguns meses que ando utilizando o Arch Linux. Ele está em dual boot com o meu fedora. Não tenho planos de sair do fedora, mas o Arch é uma distro igualmente apaixonante. Ficarei com os dois agora.

Não creio que existirá um DVD oficial para o Arch já que a ideia é nem ter interface gráfica a partir do CD de instalação. Você deve instalar e configurar tudo manualmente depois, mas não é nada complicado não. Existe, entretanto, o Chakra, uma distro baseada no Arch que vem com interface gráfica, mas acho que somente o KDE:
http://chakra-linux.org/

É, vou ter de procurar com mais calma a resposta para essa diferença depois. Na internet as respostas me parecem mais confusas que a man page do comando.. rs

Obrigado pela resposta. A questão agora é saber qual a diferença entre essas duas opções para que elas existam separadamente. No Arch parece clara, mas no fedora..

Estranho mesmo.. mas olhando a manpage do uname, vejo essa informação:

---------------------------------------------------------------------
-m, --machine
print the machine hardware name

-p, --processor
print the processor type or "unknown"
--------------------------------------------------------------------

Fiquei em dúvida agora, mas tenho a impressão que a opção -p pode retornar x86_64 mesmo se o sistema for de 32 bits, bastando para isso que tenhamos um processador de 64 bits. Pelo que entendi -- mas posso estar errado -- ele leva em conta as características do processador em si e não do sistema instalado. Já a opção -m é clássica quando se quer obter a arquitetura do sistema. Vou pesquisar mais a respeito porque agora fiquei curioso =)

Em relação aos rpms.. eu ainda tenho o plano de continuar com os pacotes que estávamos/estamos mantendo. Isso deverá sair algum dia, eu juro.. rsrs. Meu tempo e a quantidade de coisa que ando envolvido não andam ajudando muito nisso.

Em relação ao seu script, há um erro na linha 12 (para os usuários do GNOME. Não verifiquei os outros). Você tenta obter a arquitetura do sistema com o comando:

$ uname -p

Mas o correto seria:

$ uname -m

ou ainda

$ arch

Veja a saída do comando uname -p no meu caso, (usando o ArchLinux aqui, mas o mesmo deve acontecer no fedora):

$ uname -p
Intel(R) Celeron(R) D CPU 440 @ 2.00GHz

Isso quer dizer que ele sempre vai tentar instalar o repositório de 32 bits para o flash, mesmo em uma máquina de 64 bits, já que a condição "$Arch" == "x86_64" nunca será avaliada como verdadeira.

O Github não é somente para coisas grandes. Ele serve também para pequenos projetos. Eu mesmo mantenho coisas pequenas (e grandes, como um fork de um programa que uso bastante) por lá:
https://github.com/elder

Ter um repositório git (ou com um outro sistema de controle de versão) ajuda na hora que alguém quer contribuir com código porque ele simplemente faz um fork do código, modifica-o e depois envia um pull request para o autor original. Além do mais, ajuda a saber quem contribuiu com o quê, em que linha, com qual alteração, em que dia, data, hora, minuto segundo, etc. Pessoas que contribuem gostam de receber os créditos por aquilo que contribuíram, o que é mais do que justo.