Ultimamente, sempre que eu preciso fazer uma nova instalação de Linux, eu tento fazer com uma Distribuição que eu ainda não tenha usado. A idéia é que eu possa interagir com várias distribuições diferentes, conhecer os vários gerenciadores de pacotes, e quem sabe, achar uma que seja melhor, para mim, do que a que eu uso atualmente, o Gentoo.

Por isso instalei Sabayon no meu computador do trabalho. Era uma distro que eu queria testar já há algum tempo, porque ela é derivada do Gentoo, só que a idéia é que ela seja uma distro menos para curiosos, e mais para usuários. Assim, ela possui um gerenciador de pacotes próprio, o Entropy, que usa pacotes pré-compilados, assim como yum, apt-get, rpm, etc. E também ela é empacotada e finalizada com o intuito de ser usada direto do livecd.

Instalei ela porque por mais que eu goste do Gentoo, para fazer a instalação pode demorar um pouco, se você quiser fazer uma instalação completa de KDE, devido ao tempo que demora para compilar todo o ambiente. E eu queria botar tudo funcionando o mais rápido possível. Pois bem.

Entropy

O entropy parece ser um gerenciador de pacotes muito bom. É, até certo ponto, no mesmo estilo do Portage, e tem uma interface gráfica e um notificador que fica na tray para avisar quando tem atualizações. Porém, a parte gráfica dele ainda sofre de um uso absurdo de CPU. Demora um tempinho para abrir, nada absurdo, mas um tempinho que dá pra notar.

A parte boa é que ele é integrado ao Portage, então você pode, se achar necessário, misturar pacotes dos dois, desde que saiba o que está fazendo. A recomendação é não misturar muito, e usar um como principal, e o outro só pra alguns pacotes complementares.

O Acabamento

Isso eu achei bem legal, o Gentoo não é feito para ter acabamentos, pois a idéia é que você deixe tudo no seu estilo. Mas como o sabayon é meio que direcionado para media-centers e jogos, ele é bem polido, já usa Grub2 com uma imagem de fundo bem legal, o Splash dele é bem acabado também, e assim que você termina de instalar ele, você já tem no Desktop um link pro XBMC que é um media center e para um demo de World Of Goo rodando via Wine.

Há duas opções de livecd, um baseado em KDE4 e o outro em GNOME. Ambos tem a opção de instalar um sistema com Fluxbox pro caso de uma instalação minimalista.

Primeiras Impressões

As primeiras impressões foram muito boas. A única reclamação que eu tenho é que não tem mirrors mais próximos do Brasil, então os downloads muitas vezes demoram um tantinho, mas fora isso, tudo funciona como o esperado.

Recomendo pra quem tá querendo testar alguma coisa fora de Ubuntu, até gostaria de ver uma avaliação de alguém que esteja migrando do Ubuntu para ele para ver o que acha.

Então, fica aí minha recomendação: Sabayon Linux, eu aprovo ;)

Há uns dias atrás eu descobri o Paludis. O Paludis é, segundo a definição do próprio site, “the Other Package Mangler”, ou em tradução livre, o Outro destruidor de pacotes. A idéia do Paludis é substituir o Portage, o gerenciador de pacotes padrão do Gentoo. A reclamação era de que o Portage, além de ter uma resolução de dependências lenta, também era muito, digamos, conivente com certos problemas e estranhezas introduzidas ao longo do tempo.

Com isso, fizeram o Paludis, apenas se baseando no Portage, mas sem seguir estritamente as mesmas regras e idéias. Feito em C++, é supostamente mais robusto e mais fácil de manter, além de ser mais duro na hora da resolução de dependências, e com isso, evitaria certos vícios que o Portage introduziu.

Nunca tive nada a reclamar do Portage, muito pelo contrário, mas sempre que dá eu dou uma investigada em coisas novas, para não acostumar. Acredito que no mundo de hoje, especialmente no meu ramo, não dá pra ficar parado muito tempo sem aprender coisas novas :)

Pois bem, resolvi então testar o Paludis. Com um certo medinho, afinal, mudar o gerenciador de pacotes da distribuição que você usa no dia-a-dia é uma parada meio bizarra e quase certa de dar erro. Fui então testando ele no pior caso de uma vez. Estava sem atualizar o meu computador há quase um mês, e de lá pra cá, nova versão do KDE saiu, isso quer dizer, mais de 100 pacotes novos, atualizando todos os pacotes do KDE.

Pois bem, segui as orientações, instalei, fiz todos os passos para ativar o cache e tudo o mais. E tentei ver se conseguia me habilitar a ele durante alguns dias. Meu saldo final é o seguinte:

Resolução de dependências

É uma bandeira bem levantada que o Paludis resolve dependências mais rápido. Na prática? Não vi diferença. Talvez em outros casos (por exemplo, menos pacotes desatualizados na árvore), ele faça diferença. Mas no meu caso,  quase nenhuma.

Resolução de Bloqueios

Comecei a usar o Gentoo em 2007. Nessa época, alguns bloqueios mais triviais, do tipo, uma versão de um software estar bloqueando a versão mais nova dele, algumas vezes aconteciam e tinham de ser resolvidos manualmente. É um passado das trevas para o qual eu não gostaria de voltar. E foi uma das primeiras coisas que vi quando rodei o Paludis. Enquanto o Portage resolveu lindamente os blocks e perguntou apenas se eu gostaria de atualizar, o mesmo comando no Paludis mostrou um block que ele não saberia resolver.

Pelo que vi, talvez isso seja By Design, mas não gostei, anyway.

Por fim, depois de mexer um pouco mais pra lá e pra cá, desisti da experiência. Enquanto lia mais sobre esse problema das dependências vi sobre a grande possibilidade do Paludis ser substituído por um outro, o Cave, por causa de algumas mudanças que vão ser feitas  no modo como são feitas as resoluções.

Enfim, de volta ao Portage. :)

Eu sou gerente da equipe que gerencia os softwares dos laboratórios do meu departamento na faculdade, a equipe de Workstations. Basicamente, a configuração lá é um dual boot de Windows XP e Linux, usando o Gentoo como distro, já que era a que eu tenho mais facilidade.

Isso me fez mudar algumas idéias que eu tinha, evoluir outras, e me fez procurar soluções para as quais eu nunca precisei. Explico.

Há alguns anos, desde fim de 2007, se não me falha a memória, que em casa eu só uso Linux. E como eu não sou um usuário comum, isto é, eu não me incomodo de fuçar aqui e ali pra consertar as coisas de vez em quando, ou de fazer um “hack” esquisito pra alguma coisa que não funciona num determinado programa, eu acabava não dando importância quando certas coisas davam errado no meu gentoo. Coisas básicas, na verdade, quase todas de interface. Como por exemplo, o fato de que o Firefox não consegue absorver muito bem as associações de arquivos.

Quando eu entrei pra equipe de Workstations, no meio do ano passado, a distro que estava instalada na época era o Ubuntu. E uma versão do Ubuntu com pelo menos um ano de atraso. Eu “gerencio” uma instalação do Kubuntu na casa da minha namorada, e ela não é uma alternativa muito boa para um ambiente onde tantas coisas precisam estar instaladas. A ferramenta de update do (K/X)Ubuntu ainda não é 100%, e consegue fazer umas cagadas homéricas quando você faz um full-dist-upgrade, ou seja lá como isso é chamado.

Nas últimas duas atualizações do Kubuntu eu tive que reinstalar para que ele voltasse a ser 100% como deveria ser. Isso não é um grande problema quando você tem duas ou três coisas fora do padrão instaladas. Mas quando tem pelo menos 120 pacotes instalados, e muitos deles não são padrão de uso da maioria, isso começa a ficar meio preocupante.

Além disso, a filosofia do Ubuntu é muito boa para um desktop normal, e eu realmente admiro eles pelo que eles fazem. Mas eu não acho que ela seja a filosofia ideal para um ambiente onde grande parte dos usuários usa ferramentas de desenvolvimento. (É preciso lembrar que até poucas versões atrás, o Ubuntu não vinha com o gcc instalado por padrão)

O problema é que quando você muda do Ubuntu, que é uma distro com várias “especializações” para facilitar a interface, para uma distro como o Gentoo, onde a funcionalidade é mais importante, alguns detalhes passam batidos que as pessoas sentem falta. As associações do firefox, que eu citei lá em cima, são um exemplo.
O firefox não consegue, por algum motivo que eu ainda desconheço, reconhecer as associações do Desktop Manager em uso. Ele faz uso de um arquivo, que é gerado baseado no que cada aplicativo diz que aceita. Isso gera alguns resultados estranhos, como o GIMP virar padrão pra abrir PDF. (Pois o GIMP consegue abrir PDFs, ele só não é um visualizador.)

Além disso, por resolver seguir a tradição do laboratório – instalar Desktop Managers que agradem a gregos e troianos – tive a dificuldade de que esse tipo de coisa não é feita, por padrão, e por isso as pessoas não se preocupam em deixar eles amigáveis entre si. O que resultou em algumas associações bem bizarras, principalmente nos Desktop Managers que eu não uso, como o GNOME.

Mas nem tudo são erros, acredito eu. Eu venho tentando aproximar os laboratórios dos usuários, tentando fazer com que as sugestões sejam aceitas de modo mais rápido, as correções feitas de modo mais rápido. Talvez isso compense, de alguma forma, pelos bugs que eu acabei introduzindo sem querer no meio do caminho. Talvez tenha sido uma troca justa?

Uma das coisas mais discutidas, depois que o hype passou, é pra que diabos serve o Wave?

Afinal, quem já tem email não tem muita necessidade de trocar por algo que é mais lento e aparentemente tem as mesmas features, provavelmente implementadas pior, ao menos por enquanto.

E eu tenho que concordar que não tinha visto nenhuma utilidade naquela bagaça, até que semana passada eu precisei fazer um Brainstorm sobre um jeito novo de fazer uma das tarefas do laboratório que eu ajudo a gerenciar.

Como a idéia era fazer um brainstorm, eu queria que todos participassem, e o problema de usar email pra isso, é que vez por outra as pessoas esquecem de dar “reply to all” e aí a parada não funciona como deveria.

Não valia a pena criar um grupo de discussão só pra isso, já que seria só um tópico e acabou.

E aí eu abri meu wave, incluí as pessoas que queria que estivessem no brainstorm, e comecei a escrever.

Acho que finalmente achei a serventia, e por isso estou escrevendo: Usem o Wave pra situações onde pessoas possam ser incluídas depois. No caso do brainstorm, alguém podia lembrar de algum amigo que conheça bastante do assunto sendo falado e incluir para que ele pudesse falar sobre o assunto também.

Se fosse por email, teria o inconveniente de ter que repassar toda a thread original para a pessoa, além de ter que dar um jeito de incluir em todos os emails enviados dali em diante (as pessoas poderiam dar reply num email antigo da discussão, antes de ele entrar)

Ou seja, acredito que o Wave seja bom para duas situações: Brainstorms e organizações de eventos. Nesses dois casos incluir mais gente é uma possibilidade (“Hey, vou convidar fulano, tô incluindo ele no email”) e acho que no Wave isso é mais natural.

E vocês, quais serventia vocês acharam pro Wave?

Durante um bom tempo fui contra a “automatização” da computação. Achava que isso ia causar uma sucatização massiva. Achava que se o cara pudesse gerar código automaticamente, tudo ia acabar descambando pro código automático porco que não ia servir pra muita coisa. E andei até conversando com várias pessoas sobre o assunto.

E depois de conversar sobre o assunto, cheguei a conclusão de que estamos passando pela evolução que passaram os alfaiates. No princípio, tudo era feito a mão. Os alfaiates faziam as roupas, cobravam o quanto queriam por elas, pois não eram tantos os que eram mestres na profissão. E com o tempo, surgiu a indústria de roupas, o barateamento das roupas, e os alfaites, ainda existentes, caíram basicamente em desuso.

Exceto talvez pelos ternos. Já ouvi muita gente falando que terno que não é ajustado pessoalmente pra você é basicamente inútil. Não é confortável, não cai bem, etc etc.
Não uso ternos, mas já ouvi mais de uma pessoa falando isso. Fora que ternos são peças de roupas bem específicas e bem caras, também.

Por isso o paralelo, acho que com o passar do tempo a computação evoluirá para algo no molde da alfaiataria: O comum será usar fábricas de software. Software barato, rápido, que serve pro que você precisa. E só quem precisar de algo específico – só quem precisar de um terno – irá recorrer ao software feito a mão. Não completamente a mão, claro. Hoje em dia mesmo quem faz software específico não escova mais bits. O compilador ajuda muito nessas horas. Mas hoje em dia acredito que mesmo os alfaiates tem mais evolução do que tinham há anos atrás.

Eu nem sei o que a maioria das pessoas considera software específico. Eu mesmo não sei se sei. Há um tempo atrás qualquer coisa que usasse uma camada de abstração em cima do banco pra mim já começava a ficar bizarro, porque já tinha visto várias consultas desnecessariamente grandes sendo geradas pra coisas bobas. Mas hoje em dia não sei qual é o “state of the art”,  então não sei se tenho como dizer como está esse nível.

Ainda acho que automatização demais faz mal. Só gerar um UML e mandar ele gerar o software pra você não vai fazer o melhor software do mundo. Mas talvez ele esteja na medida certa pra 90%  das pessoas. E  o princípio  de pareto ainda é o mais importante. Melhor fazer 20% do esforço e resolver 80% dos problemas.

Bom, eu não sou exatamente um expert em C#, mas uso no dia-a-dia no trabalho, e ultimamente uma coisa vem me incomodando bastante na sua definição.

Primeiro, vamos deixar claro, uso .net v2.0. Ou seja, não sei se o problema foi corrigido nas versões posteriores, mas pelo que vi, não o foi.

Quando criamos um DataGrid em C#, para exibirmos dados no DataGrid precisamos especificar um DataGridTableStyle, que é o define que tipo de dado será exibido naquele DataGrid, qual será o nome de cada coluna, a ordem das colunas, etc.
Pois bem, temos então algo nesse estilo:

DataGridTableStyle estilo = new DataGridTableStyle();

estilo.MappingName = typeof(List).Name;

DataGridTextBoxColumn coluna = new DataGridTextBoxColumn();
coluna.MappingName = “Campo”;
coluna.HeaderText = “Meu Campo”;
estilo.GridColumnStyles.Add(coluna);

dataGrid1.TableStyles.Clear();
dataGrid1.TableStyles.Add(estilo);

Agora olhe bem pra esse código. Você a vê a linha que define coluna.MappingName? Pois é. Ele define uma string com o nome do campo. Sim, uma string hard-coded no seu código.
“Ah, mas qual o mal nisso?”, você pode perguntar. Como é sabido, o Visual Studio tem uma ferramenta de refactor razoavelmente eficiente. Que deixa que você modifique o nome de um campo para melhorar o seu código em poucos passos. No entanto, com o nome no campo assim numa string, isso passa a não ser mais tão útil assim, pois você tem que ir lendo todas as ocorrências da string para ver se elas são mesmas relativas ao campo que você está modificando. Se você esquecer de alguma, você terá problemas no seu programa.
Um outra caso é que em refactors algumas vezes você muda a estrutura do seu programa e aí você não pode ter certeza se o campo que você quer apagar realmente não é referenciado pois não é possível encontrá-lo sem que você busque pela string e vá vendo ponto-a-ponto.

Não é o pior problema do universo, no entanto, vai de encontro a toda facilidade de refactor estabelecida no Visual Studio.

Eu procurei e não encontrei solução para isso, e fiquei bem decepcionado. Tive que usar de truques pra encontrar essas coisas no código, como declarar uma variável temporária do mesmo tipo da Classe usada na Lista para poder usar o refactor.

Vocês conhecem uma solução melhor?

Bom, a verdade é que me deu uma vontade louca de falar sobre o DS esses dias. Eu tô nessa de DS desde novembro de 2007, basicamente 1 ano depois do lançamento do DS Lite.

Então vou fazer uma série de posts falando sobre o DS e como ele chegou ao que é hoje, pelos meus olhos. Vou falar principalmente da parte de homebrew, porque acho que é a parte onde complica.

No primeiro post eu falei de origens, do GBA e dos primeiros flash carts, sem entrar em muitos detalhes.

No segundo post eu falei sobre a infância do homebrew no DS e o que era o DS quando eu comprei o meu.

Nesse terceiro e último post eu vou falar sobre como vejo hoje em dia o DS.

R4: Ladrão que rouba ladrão…

É fácil de ver que quando um produto faz sucesso, o que mais acontece é ele ser copiado até a exaustão (Vii, Polystation, dentre outros), e se isso acontece com produtos oficiais legalizados e tudo mais, imagina como não é com um flash cart, que está numa área muito cinza da legalidade?

Depois que o R4 ficou famoso, o que mais começou acontecer foram os inúmeros clones dele. Primeiro, clones com o mesmo nome, ou seja, R4 falsificados. Depois que isso ficou muito na cara, começaram a surgir clones com outros nomes. Até porque, e isso eu não sei dizer corretamente, o R4 tem um hardware igual ao M3, e eu não sei qual deles veio primeiro. Mas aí veio também o G6, o R4 SDHC, e tantos outros clones espalhados por aí.

Aí eu fico até com um pé atrás de recomendar algum flash cart quando alguém me pergunta. Porque como eu vou dizer qual deles é o melhor pra comprar? Se o R4 já hoje em dia tem grandes incompatibilidades, o que dizer dos clones?

E até onde os clones são compatíveis com os firmwares, originais ou não?

A boa coisa do R4 original é que ele roda, por exemplo, o YSMenu, que é o firmware do DSTT modificado para rodar no R4 (o que aumenta a compatibilidade, já que o R4 não tem mais seu kernel atualizado desde ’08).

Claro que além do R4, existem outros chips como o próprio DSTT, o CycloDS ou o Acekard, mas não tenho conhecimento de causa suficiente pra recomendar nenhum deles, e não sigo de perto os lançamentos em cada um pra saber como funcionam os lançamentos recentes neles.

Por isso, fica a conclusão, ao comprar seu Flash Cart hoje em dia, tome um cuidado extra. Pesquise bem nos fóruns antes de comprar seu DS pra não ficar arrependido depois.

Bom, a verdade é que me deu uma vontade louca de falar sobre o DS esses dias. Eu tô nessa de DS desde novembro de 2007, basicamente 1 ano depois do lançamento do DS Lite.

Então vou fazer uma série de posts falando sobre o DS e como ele chegou ao que é hoje, pelos meus olhos. Vou falar principalmente da parte de homebrew, porque acho que é a parte onde complica.

No primeiro post eu falei de origens, do GBA e dos primeiros flash carts, sem entrar em muitos detalhes.

Nesse segundo post eu vou falar sobre a infância do homebrew no DS e o que era o DS quando eu comprei o meu.

DS: Pegando carona numa onda que já vinha

Quando o DS saiu com seus dois slots, quem já estava desenvolvendo em GBA pensou logo em usar aquela entradinha safada de GBA, chamada Slot-2, pra continuar o que já fazia usando o DS. Já que o DS roda GBA nativamente, a maioria das coisas feitas pela cena homebrew de GBA podia ser aproveitado sem problemas no DS. Óbvio que sem usar todo o seu potencial, mas ainda assim, usado.

Naquela época, o que foi feito foi usar um dispositivo semelhante ao que já era usado no GBA, porém melhorado, e para conseguir fazer ele funcionar para jogos de DS, foram usados métodos que enganavam a firmware do DS. Estão aí incluídos dispostivos como o SuperKey e o FlashMe, um firmware modificado para o DS.

Era então um pouco complicado esse início. Era necessário adquirir um cartucho para o slot-1 como o superkey, um flash cart para o slot-2 para botar os jogos, e aí sim era possível usar. Não era muito complicado, mas pra quem era leigo, a coisa começava a enrolar.

Depois de algum tempo, a encriptação do DS foi quebrada, e com isso os cartuchos para SLOT-1 puderam ser fabricados, no início, com compatibilidade pequena, mas aos poucos foi aumentando e se equiparando aos cartuchos de SLOT-2, que já estavam mais consolidados. Nessa época passa a ser possível comprar somente um cartucho, alguns com memória interna, outros aceitando cartões externos, como MicroSD.

Cartuchos de SLOT-1 tem a desvantagem de que não é possível jogar GBA diretamente deles. Para jogar jogos de GBA a partir de um cartucho de SLOT-1 é necessário outro dispositivo no SLOT-2 que sirva somente para isso. Dispositivos de SLOT-2 também tem a vantagem de aumentar a memória do DS, como é o caso do cartucho do Opera DS.

Nessa época que eu comprei meu DS. Na época, o Flash Cart mais proeminente era o R4. Claro que haviam outros, mas era o que tinha melhor custo x benefício.

O R4 tinha a vantagem de ter seu firmware colocado dentro do MicroSD, como é comum nos flash carts, e seu firmware era atualizado com frequência, para corrigir eventuais jogos novos que não funcionavam.

Mas claro que isso atraiu os olhos de outros piratas.. E é aí que entra a 3ª parte da minha história :)

Bom, a verdade é que me deu uma vontade louca de falar sobre o DS esses dias. Eu tô nessa de DS desde novembro de 2007, basicamente 1 ano depois do lançamento do DS Lite.

Então vou fazer uma série de posts falando sobre o DS e como ele chegou ao que é hoje, pelos meus olhos. Vou falar principalmente da parte de homebrew, porque acho que é a parte onde complica.

Nesse primeiro post vamos falar de origens, vamos falar do GBA.

Nintendo GBA: Onde tudo começou

Antes do GBA, pirataria em consoles com fitas era um pouco mais complicado. Não que não existissem jogos piratas, mas você tinha que ir em algum fornecedor e comprar o jogo pirata, e só assim você ia rodar um jogo não oficial no seu portátil.

Sempre existiram cartuchos em que era possível escrever, mas em geral esses cartuchos ficavam de posse dos desenvolvedores. Existiam alguns dispositivos para fazer backups de cartuchos mas eram caros e basicamente difíceis de conseguir, ao menos no Brasil. Eram exemplos o Game Doctor SF, pra SNES. E em especial, a Bung, que fez acessórios semelhantes para Nintendo 64, Neo Geo, e GB/GBC. [1]

Embora nos EUA o Doctor V64, dispositivo de backup da Bung para N64, tenha feito sucesso, o terreno ainda não era propício, roms de N64 eram grandes pra internet na época. Era difícil armazenar um arquivo que tinha entre 4Mb e 16Mb em servidores online.

Não achei dados, mas acredito que o GBA tenha coincidido com a época do barateamento das memórias flash, como cartões de câmera, pendrives e etc. Com isso, foi muito simples fazer um cartucho nesse estilo e fazê-lo ficar barato e atrativo, com um espaço razoável. Além disso, na época, era muito fácil disponibilizar os jogos online. Fazendo assim um terreno fértil para acessórios do gênero.

Assim, ao fim da vida do GBA, era possível você comprar um dispositivo chamado Flash Cart (cartucho Flash), um exemplo era o Extreme Flash Advance, e passar seus jogos baixados da rede pra ele, e então jogar no seu GBA, sem emuladores. Assim começa o homebrew do DS.

[1] http://en.wikipedia.org/wiki/Bung_Enterprises

Quando o Chrome foi lançado foi um grande estardalhaço. Vozes se elevaram falando sobre a possível morte dos outros browsers em face a um browser suportado pela Google. Com o grande gigante da internet apoiando um Browser, como poderia ser diferente?

Aos poucos as pessoas viram que não era bem assim. Pra começo de conversa, depois de pesquisas, descobriram que os usuários nem sabiam o que era o browser. E muita gente nem tinha idéia de como usar o Chrome no lugar do Internet Explorer que eles aprenderam a usar desde sempre.

Depois, esbarraram no segundo problema, o ambiente corporativo. Como muita gente sabe, existem zilhões de sistemas de intranet desenvolvidos para IE (mais especificamente, IE6) e por isso, em muitos ambientes corporativos não há a opção de mudar de browser, porque não há sentido em gastar dinheiro migrando um software que está funcionando para outro simplesmente porque a internet chora contra o IE6.

Mas dentre os power users, o chrome foi ganhando mais e mais momentum, comigo foi diferente porque, como muita gente sabe, em casa eu só uso linux há uns dois anos, e ainda não tinha versão do chrome para Linux. Depois apareceu um alpha mas dava muito trabalho pra instalar. E finalmente semana passada eu vi uma versão do chromium (a engine open-source por baixo do Chrome) para instalar no Gentoo.

Minhas primeiras impressões foram as melhores possíveis. Tudo funcionou sem dor de cabeça: Flash, Java. Ao contrário do Firefox, associações de arquivo também funcionaram maravilhosamente, pdf abre no meu aplicativo favorito do KDE.

A velocidade em relação ao firefox é impressionante. Embora a versão de Windows tenha ficado mais rápida quando pulou para a 3.5, a versão de linux continuou muito lenta. E pesada. E bugada. A mozilla parece não ligar para o segmento linux, mas até faz sentido, já que seu Market Share é principalmente formado por usuários Windows.

Eu sei que o Firefox vai ficar abandonado por aqui. Estou usando só para links que não funcionam corretamente no Chromium, que até agora são poucos. E recomendo a quem puder, testar o Chromium também.