Continuando a temporada de lançamentos, nesse fim da semana saiu Firefox 3 RC1. Com isso, podemos dizer que nas próximas semanas (de acordo com o cronograma de Mozilla), vamos ter a versão final do Firefox 3.0.
Eu estou usando ele desde o fim do ano, nas versões conhecidas como “nightly” (com codenome “minefield“) - são as versões compiladas diariamente. Isso tem lados positivos e negativos - entre os positivos, o desempenho dessas versões geralmente é significativamente superior ao das mais oficiais. Entre os negativos - vire e mexe algo para de funcionar (por exemplo, gmail, acentos, teclado, etc, etc). Mas em geral eu gostei da experiência que eu tive com os nightlies.
Porém, recentemente - já faz aproximadamente 1 mês - ele tem 2 problemas extremamente irritantes:
- O acesso ao chrome (i.e., páginas “internas” do browser) foi desabilitado. Com isso, extensions como yardvark (para remover partes das páginas - tipo banners, fontes ilegiveis, etc) e webdeveloper (caixinha mágica dos web-developers
) pararam de funcionar. Enquanto o webdeveloper - de acordo com o site do seu criador - ainda tem esperança, o outro aparentemente não vai ser atualizado no futuro previsível…
- Os atalhos (alt-número) para trocar de tabs pararam de funcionar de vez no Linux. Isso é mais de que irritante. Inclusive eu achei o commit que quebrou isso, mas, apesar da minha experiência com o código do mozilla, não estou nem um pouco animado a mexer com isso.. hehehe
Mas, fora isso, o desempenho dos nightlies é mais de que suficiente, e qualidade de renderização também.
E, por falar em desempenho.. Acredito que muitos já perceberam que o Firefox para windows ganhou um speedup de até 4x na renderização de páginas, javascript, e funcionamento em geral. Tudo isso foi possível graças ao PGO (profile-guided optimizations) - técnica nova que apareceu nas últimas versões do GCC (junto com uma multidão de problemas, o gcc também trouxe coisas boas nas versões mais recentes ). Entretanto, só versões para windows são compiladas com esse suporte; as de Linux não.
Eu tentei dar uma chance a essa técnica - já que o Arch Linux, que estou usando no último ano-e-pouco, tem facilidade muito grande para criação de pacotes otimizados. E, realmente, a diferença de desempenho é MUITO grande. Não vou colocar nenhum benchmark nem nada aqui, só a minha opinião subjetiva. E ela é:
LIGUE JÁ O PGO!
hehehe.
(se você quer ver um benchmark, dê uma olhada aqui por exemplo -Firefox 3 ainda mais veloz | Open Mania).
E é isso. De forma geral, o firefox 3 parece ser muito melhor que o 2, vamos esperar o release final!
Só um pequeno resumo de vantagens e desvantagens de sistemas de controle de versões distribuídos que eu já cheguei a usar.
- SVN + SVK - parecido com SVN, tem os mesmos problemas que ele (cria um monte de diretórios, etc). Na minha opinião, não tem muito uso prático - é melhor usar soluções distribuídas mesmo (bzr, git ou mercurial), porque todas elas tem gateways para SVN propriamente dito.
- BZR - acho que é o meu favorito para a maioria das coisas. Facil de usar (o mais fácil de todos, na minha opinião), rápido - principalmente nas últimas versões, extensível. Os meus maiores problemas com ele foi o desempenho (que foi resolvido na versão 1.0), e o tratamento de arquivos binários grandes - ele fazia questão de colocar o commit inteiro na memória, em formato ASCII ainda. Ou seja, para fazer commit de 100MB ele usava 2GB de RAM. Mas aparentemente, isso foi arrumado recentemente.
- GIT - extremamente poderoso, rápido e eficiente.Em contra-partida, ele tem milhares de comandos, sub-comandos, parâmetros e opções. Se você aprender tudo com ele, ele é o melhor. Entretanto, eu vivo me perdendo na hora de fazer coisas mais complexas (tipo, fazer um cherry-pick de um repositório remoto em um branch diferente). Por outro lado, só ele que permite fazer cherry-pick de forma fácil (para quem está por fora - cherry-pick permite você pegar um commit independente e embutir ele em outro branch. Se isso não fez sentido para você, provavelmente você não precisa dele :)). A melhor coisa do GIT para mim é o suporte dele para multiplos branches locais, no mesmo diretório. E a velocidade, é claro. Porém, a complexidade dele acaba complicando demais a vida as vezes.
- Mercurial - parecido com o BZR e GIT. Atualmente suporta branches e cherry-picks também (de forma diferente). Ele suporta queues de patches também nativamente - mas, como nunca precisei disso, não posso falar muito detalhes. Fora isso, nunca cheguei a mexer muito com ele (mas, para quem tiver interesse, tem um tutorial interessante aqui). A escolha entre ele, bzr e git muitas vezes é questão de religião mesmo :).
- DARCS - bastante interessante, e diferente de todos os outros sistemas. Basicamente, todo o mecanismo de commits e diferenças entre versões dele é baseado em filas de patches, aplicados em determinada ordem. A filosofia dele também é parecida com GIT - ele visa manter controle do conteúdo, e não da estrutura de versões. Isso tem lados bons (o mesmo conteúdo pode migrar de um lugar para outro - arquivo, diretório, etc) e ruins (se alguém fez essa migração, você não vai ter controle exato sobre o que foi feito).
- GNU ARCH - acredito que hoje em dia ele tem mais interesse histórico de que prático. Muito mais complexo de usar (se bem que, comparando com GIT, acho que dá uma briga boa). As ideias dele são utilizadas em outros sistemas de controle de versões distribuídas, mas ele em si - pelo que eu sei - está parado. Eu cheguei a usar ele faz alguns anos, mas desisti logo devido à complexidade dele.
- MONOTONE - também em desuso nos últimos tempos, o MONOTONE serviu como inspiração para GIT. Fora isso, nunca vi ninguém usar ele, então não tenho opinião formada sobre ele.
Além disso, tem diversas outras soluções caseiras (com svn, cvs (eca..), etc) que fazem a mesma coisa que DRCS’es usando algumas gambiarras (hehehe). Mas eu fico entre BZR e GIT na maioria dos casos.