Tive meu primeiro contato com o Chrome OS, o sistema operacional da Google, em 2011 quando escrevi um artigo sobre os Chromebooks para a PC World. Aliás, creio que fui o primeiro a fazer um “hands-on” do sistema no Brasil. Na época tanto o hardware quanto o software eram protótipos (gentilmente cedidos por Felix Ximenes, na época Diretor de Comunicação da Google no Brasil), mas já mostravam potencial.
Desde então acompanhei a evolução do sistema a uma certa distância, porque aqui no Brasil não temos a mesma oferta (nem os mesmos preços) de hardware compatível que há no exterior. Mas há cerca de um ano comecei a trabalhar na Positivo Tecnologia Educacional, que tem um Chromebook (o CH1190) como um de seus produtos. Era minha chance de me familiarizar mais com a plataforma.
E mesmo com hardware bastante modesto (um processador ARM e 2 GB de RAM) o Chromebook e o Chrome OS impressionaram. Em vários momentos o portátil se mostrou mais rápido que meu PC Desktop, e ele logo se tornou meu “companheiro”, a máquina favorita para levar em reuniões, apresentações, viagens e outra qualquer situação onde eu precisasse de acesso rápido à informação e longa autonomia de bateria.
A experiência me marcou: se um Chromebook de entrada já oferece uma experiência de uso tão boa, do que o sistema seria capaz em hardware mais poderoso? Será que o Chrome OS já está maduro o suficiente para substituir o Windows, Mac OS ou Linux no dia-a-dia?
Para responder a esta pergunta, decidi passar um mês usando o Chome OS como meu sistema operacional principal. Mas em vez de comprar um Chromebook, apelei para uma solução mais econômica: fiz o meu, reaproveitando um notebook que já tinha em casa.
Instalei há cerca de um mês o Linux Mint 19 “Tara” em meu notebook, e desde então venho percebido um comportamento estranho: algumas vezes a máquina congela ao voltar da hibernação (quanto mais tempo hibernando, maiores as chances), em outras ela volta da hibernação mas vejo a mensagem “Read-error on swap-device” no console. Como o “swap device” é uma partição no HD, a princípio suspeitei de falha no disk, mas uma checagem do status via S.M.A.R.T. mostrou que tudo estava OK.
Pesquisando um pouco no Google, descobri que os travamentos e mensagens são causados por um bug na versão 4.15 do kernel Linux, que foi corrigido na versão 4.17. Ou seja, a solução é atualizar o kernel. A versão 4.17 ainda não está nos repositórios oficiais do Mint, então devemos adicionar um novo repositório e instalar a ferramenta ukuu (sério, é esse o nome) para fazer o serviço. Seguem os passos, baseados em um artigo que encontrei no site mintguide.org.
Agora atualize a lista de kernels disponíveis, com
ukuu --check
Você pode ver quais versões do kernel estão instaladas em seu sistema com ukuu –list-installed e remover quaisquer versões mais antigas que o kernel atualmente em uso com ukuu –purge-old-kernels. Isso é especialmente útil em sistemas que estão em uso há um bom tempo e vem sendo constantemente atualizados. Em minha máquina, por exemplo, encontrei seis versões que não uso mais.
Para instalar o kernel estável mais recente, use
ukuu --install-latest
Com isso o ukuu vai baixar e instalar o kernel mais recente (junto com os headers) e atualizar o grub. Agora é só reiniciar o micro. O kernel antigo fica disponível como uma opção no menu do grub, caso você queira voltar a ele.
Faz um tempinho que estou brincando com um custom firmware para a upscaler GBS-8200, que uso para ligar meus consoles e computadores clássicos à minha TV LCD. Chamado GBS-Control, esse firmware corrige algumas deficiências do original, melhora o desempenho geral da placa e adiciona alguns novos recursos interessantes. Há toda uma discussão sobre o desenvolvimento do GBS-Control no fórum Shmups.
Para usar o GBS-Control é necessário fazer algumas pequenas modificações na GBS-8200, para acoplar a ela uma Arduino ou compatível. É a Arduino que irá rodar o firmware, assumindo controle do conversor de vídeo da GBS-8200. Fiz essa minha modificação em minha placa há algum tempo atrás e documentei o processo em dois vídeos no YouTube (parte 1 e parte 2).
Mas a Arduino é apenas a ponta do Iceberg. Se no lugar dela você usar uma placa mais sofisticada, porém ainda compatível, como a WeMos D1 sua GBS-8200 ganha “superpoderes” como gerador de scanlines, controle remoto via Wi-Fi e várias opções para ajuste fino da posição e geometria da imagem. E o melhor é que a WeMos D1 é barata: comprei a minha por R$ 30 no Mercado Livre. E a instalação dela na GBS-8200 é fácil: basta tirar a Arduino e colocar a WeMos D1 no lugar.
Uma WeMos D1
Mas antes você precisa programar a WeMos D1 com o GBS-Control. E como sou um novato completo nesse mundo de Arduino e afins, patinei um pouquinho até encontrar o caminho das pedras. Por isso decidi compartilhar um passo-a-passo aqui neste artigo, acompanhando o vídeo que fiz sobre a modificação e postei lá no YouTube.
Estas instruções parecem complexas, mas você não vai levar mais do que 10 minutos para fazer tudo. E o resultado final vale a pena, acredite em mim. Olhe esse detalhe de Streets of Rage 2 rodando numa GBS-8200 com a WeMos D1.
Detalhe de Streets of Rage 2 rodando em uma TV LCD de 32″ a 1280 x 960 pixels através de uma GBS-8200 modificada com o GBS-Control e WeMos D1
Passo 1: Adicionando o suporte à WeMos D1 na Arduino IDE
Antes de mais nada, assumo que você já tenha o ambiente de desenvolvimento do Arduino (Arduino IDE) instalado e funcionando em sua máquina. Estas intruções foram testadas com a versão 1.8.5. Se você usa Linux, uma dica: baixe a IDE do site oficial, e não de um repositório de sua distribuição. Em casa uso o Linux Mint, e a versão que veio via APT era pré-histórica: 1.0.5.
A Arduino IDE não sabe o que é uma WeMos D1, então precisamos baixar um pacote para adicionar suporte a esta placa. Abra a interface e clique em File / Preferences. Na janela que surge, na aba Settings, cole a seguinte URL no campo Additional Board Manager URLs:
Adicione uma URL extra para que o Board Manager da Arduino IDE possa baixar o pacote de suporte à WeMos D1
Agora clique em Tools / Board / Boards Manager. Na janela que surge, selecione a opção esp8266 by ESP8266 Community e clique no botão Install. Agora você deve ver a opção WeMos D1 R2 & mini em Tools / Board.
Este é o pacote para adicionar o suporte a WeMos D1 (e outras placas baseadas no ESP8266) à Arduino IDE.
Passo 2: habilitando o acesso à WeMos D1
Estes passos se aplicam apenas a quem usa Linux, como eu. Plugue sua WeMos D1 ao PC, abra a Arduino IDE, clique em Tools e observe a opção Ports. Se ela estiver desabilitada (acinzentada), você vai precisar fazer alguns passos extras antes de usar a WeMos D1, já que ela não foi reconhecida pelo sistema. Se a opção Ports estiver habilitada, pule para o passo 3.
Quem me deu o caminho das pedras foi o Steve Kemp. Todo dispostivo USB tem uma identidade composta pelo ID do fabricante (Vendor ID) e do produto (Product ID), e precisamos descobrir os IDs da WeMos. Para isso, antes de plugar a placa ao seu computador, digite o comando lsusb. Você vai ver algo parecido com isso:
Bus 002 Device 005: ID 1a2c:2d23 China Resource Semico Co., Ltd
Bus 002 Device 006: ID 04ca:3005 Lite-On Technology Corp.
Bus 002 Device 003: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0ac8:c342 Z-Star Microelectronics Corp.
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Não se preocupe se os IDs e nomes que aparecerem em sua máquina forem diferentes, afinal a lista acima mostra o que está plugado à minha máquina. O que importa é o passo seguinte: plugue a WeMos ao PC e rode novamente o comando lsusb. Compare com o resultado anterior, e você verá uma linha extra com algo como:
Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Esse é o conversor USB↔Serial integrado à WeMos. Anote o Vendor ID (no meu caso 1a86) e Product ID (7523) listados em sua máquina. Atenção: não copie simplesmente os IDs que estou mencionando aqui, pois eles podem ser diferentes em sua placa.
Agora vamos criar uma “regra” do udev (o gerenciador de dispositivos no Linux) que vai dizer ao sistema o que fazer quando a placa for plugada. Como root, digite:
cd /etc/udev/rules.d
pico 99-wemos.rules
Isso vai abrir o editor de texto Pico. Cole o conteúdo abaixo:
Lembre-se de substituir os valores em idVendor e idProduct pelo Vendor ID e Product ID mostrados em sua máquina. Tecle Ctrl-X para sair do editor, e responda Y quando ele perguntar se você quer salvar o arquivo.
Recarregue as regras do udev com o comando abaixo:
# /etc/init.d/udev reload
Desplugue sua WeMos D1 do PC, plugue novamente e ela deve ser reconhecida na Arduino IDE.
Passo 3: instalando a biblioteca WebSockets
Estamos quase no final. Para compilar o GBS-Control você precisa da biblioteca WebSockets instalada na Arduino IDE. Para isso, clique em Sketch / Include Library / Manage Libraries. Na janela que surgir, clique no campo Filter your search… e digite WebSockets. O pacote que queremos é o WebSockets by Marcus Sattler, em minha máquina ele era o último da lista. Clique sobre ele e no botão Install.
Adicione a biblioteca WebSockets à Arduino IDE antes de compilar o gbs-control
Passo 4: compilando o GBS-Control
Agora sim podemos compilar o GBS-Control. Acesse a página do projeto no GitHub, clique no botão Clone or Download e selecione a opção Download ZIP. Descompacte o arquivo gbs-control-master.zip e você deve ter uma pasta chamada gbs-control-master contendo o código-fonte do GBS-Control.
Renomeie a pasta gbs-control-master para gbs-control. Este passo é importante: não sei porque motivo, mas a Arduino IDE insiste que todo sketch (programa) esteja contido em uma pasta com o mesmo nome. Como o sketch se chama gbs-control.ino, ele tem que estar dentro de uma pasta chamada gbs-control.
Abra o arquivo gbs-control.ino na Arduino IDE e clique em Sketch / Verify/Compile. Depois de alguns minutos, a mensagem Done compiling. deve aparecer acima da janela de status no rodapé da tela. Agora é só clicar em Sketch / Upload e esperar a transferência do programa para a placa.
Resultado da compilação do GBS-Control
Ufa! Sua WeMos D1 está prontinha e programada com o GBS-Control. Agora é só seguir os passos do meu vídeo no YouTube para conectá-la à sua GBS-8200 e se divertir. Até mais!
Boa notícia para os proprietários do MD Play: a dupla Neto e Rafael Muller, que está trabalhando em melhorias de som e software para o Novo Mega Drive, lançou uma versão de seu bootloader compatível como o Mega Drive portátil da TecToy. Com isso o aparelho tem uma melhoria drástica no som, que fica muito mais próximo do console original, o que torna a experiência de jogo muito melhor. A instalação é muito fácil e não modifica permanentemente o console, mas será necessário mudar a estrutura de pastas do cartão. Basta seguir os passos abaixo.
Montando o cartão
Baixe a versão mais recente do MDI (Mega Drive Init) na página do Neto. No momento em que escrevo isso, é a Neto_MDI_1_09a.rar.
Descompacte o arquivo no HD de seu computador. Você terá 8 arquivos com a extensão .bin. Descarte o MDI.bin (que é para o Novo Mega).
Crie as pastas TECTOY e GAME na raiz do seu cartão SD.
Na pasta GAME do cartão, coloque o arquivo Neto_Boot_Loader.bin
Dentro da pasta TECTOY crie as pastas DATA e ROM
Dentro de DATA, coloque os arquivos ROM1.bin a ROM6.bin.
Dentro de TECTOY/ROM, crie as pastas ROM1, ROM2, ROM3, ROM4, ROM5 e ROM6.
Coloque as suas ROMs (com extensão .bin ou .md) dentro destas pastas. Para facilitar a navegação, eu costumo colocar no máximo 30 ROMs por pasta, mas já coloquei quase 100 sem problemas.
Carregando o novo menu
Com o cartão preparado, coloque ele em seu MD Play e ligue o console. Ao ver o menu inicial, pressione Esquerda, selecione a opção SD Card e pressione Start. Você verá uma tela com apenas um “jogo” listado, o Neto_Boot_Loader. Aperte Start para carregar o novo menu.
Antes de carregar um jogo é possível definir opções como a frequência da tela para os jogos Europeus.
Surge uma tela inicial, com algumas opções de configuração. Aperte B para ativar o modo Europa 60 Hz, ou em alguns jogos o LCD pode sair de sincronia (imagem “rolando”). Em alguns segundos o menu do Novo Mega Drive apacerá na tela.
A partir daí basta selecionar a pasta ROM com seus jogos e o jogo que deseja jogar. Start inicia o jogo, como no menu original. Sempre que você apertar o botão Menu o console irá voltar para o menu de fábrica, então você terá de repetir o procedimento para carregar o novo menu do início.
O menu é o mesmo usado no Novo Mega Drive
Assim que conseguir fazer uma captura decente, posto aqui um “antes e depois”. Mas vá por mim, essa modificação é essencial para qualquer proprietário do MD Play.
ATENÇÃO: Este post está desatualizado. Clique aqui para conhecer uma solução muito melhor para o som do MD Play.
Há cerca de 8 anos a Tec Toy lançou no Brasil um produto bastante interessante: o MD play, um Mega Drive portátil. Muito menor que um Nomad, com uma boa tela colorida e baterias que duram mais do que 45 minutos, parecia a forma ideal de levar os jogos favoritos do Mega Drive para onde quiser.
Só tem um probleminha: o som do MD Play é horrendo. Não sei como a TecToy deixou passar isso, mas boa parte das músicas toca uma oitava abaixo do que deveria, e o PSG (chip responsável por vozes e efeitos sonoros) está distorcido. Para um console com muitas músicas memoráveis, é um pecado mortal.
O MD Play da TecToy. MegaDrive de bolso, mas som deixa a desejar.
Comprei um MD Play há cerca de 2 anos esperando usar a carcaça para um Raspberry Pi portátil, mas o projeto nunca foi pra frente e ele ficou guardado numa gaveta. Até que nesta semana, vendo alguns vídeos sobre melhorias de som feitas no Novo MegaDrive da TecToy, vi uma menção a uma solução similar para o MD Play feita por um desenvolvedor russo e resolvi experimentar.
E não é que funciona? O som, embora ainda não seja perfeito, fica muito mais próximo ao original do console, e com isso a experiência de jogo fica melhor. E o mais legal é que a “modificação” é feita puramente em software e reversível se você não gostar do resultado. Veja como fazer:
Preparando o cartão de memória
Baixe este arquivo, que contém uma versão corrigida da BIOS/Menu usada no MD Play.
Retire o cartão de memória de seu MD Play e coloque ele em seu PC.
Renomeie a pasta GAME do cartão de memória, onde estão seus jogos, para ROMS.
Crie uma nova pasta GAME no cartão de memória.
Descompacte o arquivo baixado e copie o arquivo MenuForced_20111026.binpara dentro da pasta GAME no cartão.
Ejete o cartão do PC e insira em seu MD Play.
Usando o novo menu
Ao ligar seu MD Play, ele vai mostrar o menu padrão de fábrica. Aperte Direita duas vezes, selecione a opção SD Card e aperte Start.
O console vai mostrar um menu com um fundo amarelo e apenas um “jogo” no cartão, o MenuForced_20111026.bin. Selecione-o com Start.
A mensagem Loading Game vai aparecer na tela por alguns segundos, e o console vai aparentemente voltar pro menu principal. Não se preocupe, está tudo certo: na verdade esse já é o novo menu corrigido. Selecione SD Card e aperte Start.
O console agora vai mostrar todos os seus jogos que estão na pasta ROMS. É só escolher um, apertar Start e jogar.
A diferença na qualidade do som é bem clara. Compare, por exemplo, a música da 1ª fase (Green Hill Zone) de Sonic 1 com a BIOS original e com a nova versão. Ou então Idaten em Shinobi III. A solução não é perfeita, aqui e ali você pode notar algumas diferenças no áudio ou notas “dissonantes”, mas é um grande avanço em relação à BIOS original.
Este truque só tem um porém: o novo menu não consegue carregar os jogos da memória interna do aparelho, o console mostra apenas uma tela preta. A solução é carregar estes jogos no menu original (o que aparece ao ligar o console) ou então colocar uma ROM do jogo na pasta ROMS para jogar com o som corrigido. Divirtam-se!
Com o lançamento do preview para desenvolvedores do Android L, não demorou para que vários componentes do sistema fossem desmembrados e espalhados pela internet. Nesta thread no XDA Developers você pode encontrar alguns dos novos apps, papéis de parede, ringtones e alarmes, fontes e até a animação de boot, que é mostrada ao ligar o smartphone, enquanto o sistema carrega.
Só por farra, adaptei a animação de boot para a tela do RAZR MAXX, e ela deve funcionar também em qualquer smartphone com uma tela da mesma resolução (540 x 960 pixels). Para usá-la você vai precisar de um smartphone com root, no caso do MAXX siga as instruções aqui.
Voltei a usar um Motorola RAZR MAXX como meu smartphone no dia-a-dia há cerca de uma semana, mas o desempenho do aparelho com a última versão oficial do sistema da Motorola (Android 4.1) estava deixando a desejar. Ele estava “engasgando”, às vezes por vários segundos, mesmo em tarefas simples como abrir o Chrome ou alternar entre apps, e por duas vezes congelou completamente me obrigando a um desligamento forçado (segure Power + Diminuir Volume até o aparelho desligar).
A solução? Instalar uma versão modificada, mais ágil e não-oficial (uma “ROM”) do Android. Por sorte a equipe de desenvolvimento de uma das ROMs mais populares, a CyanogenMod, está lançando versões estáveis do CyanogenMod 11 (Android 4.4.2) para o RAZR MAXX.
O processo de instalação é documentado, geralmente em inglês, em várias páginas na web. Mas como caí em duas ou três pegadinhas no caminho e a informação está espalhada, achei que seria interessante condensar tudo em um único artigo para ajudar quem pretende seguir na mesma direção.
São três etapas: fazer “root” no smartphone, instalar um app chamado SafeStrap que vai nos permitir instalar a ROM nova sem afetar ou apagar o sistema original da Motorola e instalar o CyanogenMod.
Mas antes, UM AVISO: este processo provavelmente invalida a garantia de seu aparelho, e se feito incorretamente pode causar danos ao sistema e transformar o smartphone em um peso de papel (o popular “brick”). Não seja apressado, leia e releia cada passo antes de prosseguir. Não me responsabilizo por danos que possam vir a ser causados caso você decida seguir estas instruções.
Dito isto, faça um backup dos arquivos em seu smartphone, separe uma hora do seu dia, contando o tempo para download dos arquivos e para ler com calma este guia, pegue uma xícara de café e mãos à obra!
Há tempo não uso mais o Linux como sistema operacional em minhas máquinas. Em 2005 migrei para o Mac OS X em meus computadores domésticos (como fizeram muitos colegas dos tempos de Conectiva), e profissionalmente uso o Windows desde 2008.
Na verdade acredito que o “sistema operacional” é cada vez menos relevante. O que importa são os aplicativos que uso para realizar as tarefas do dia-a-dia, e no meu caso boa parte deles está na web. Pra que gastar 20 GB de espaço em disco com Windows e Office quando uma janela do Google Docs me atende da mesma forma? E uma boa experiência recente com um Chromebook em um review para a PCWorld reforçou esse ponto de vista.
Foi quando terminei o review do Chromebook e voltei a usar meu PC “velho de guerra” na redação que notei o “peso” de um sistema e apps tradicionais. O tempo de boot, a demora para abrir o Outlook 2013, os engasgos no streaming de áudio sempre que eu trocava de app ou abria uma nova aba no navegador. Isso num PC com um processador Core 2 Duo Dual Core de 1,6 GHz e 4 GB de RAM.
Daí pensei em procurar um sistema mais “leve”, que me oferecesse a agilidade do Chrome OS. Há uma versão não oficial do Chrome OS (baseada no código Open Source) distribuída por um hacker conhecido como Hexxeh, mas a última compilação foi em abril deste ano, e em testes que fiz anteriormente a compatibilidade com o hardware e a estabilidade deixaram a desejar.
Pensei em uma solução baseada em Linux e foi aí que tropecei no Crunchbang, uma distro baseada no Debian e no gerenciador de janelas OpenBox. O bichinho VOA! A imagem ISO tem cerca de 750 MB, instalei em um pendrive de 2 GB que estava no fundo da gaveta usando o Universal USB Installer e fiquei impressionado.
Vou à CES 2012 no próximo final de semana, e preciso de um “computador” para trabalhar remotamente e enviar textos, imagens e vídeos para a redação. No ano passado fiz isso com o iPad mas nesse ano pensei em levar um Motorola Atrix + Lapdock.
O problema, por incrível que pareça, é que é difícil conseguir uma conexão confiável à Internet numa das maiores feiras de tecnologia do mundo. As redes de telefonia celular ficam congestionadas, o Wi-Fi da sala de imprensa idem, e não há Wi-Fi nos pavilhões. Tenho que estar preparado para trabalhar o máximo possível “offline”.
Aí é que está o problema: sem uma conexão à internet a Lapdock do Atrix é um peso de papel. O único aplicativo que roda no modo Webtop (com o aparelho plugado à Lapdock) é o Firefox, e embora online eu consiga editar textos (com o Google Docs) e imagens (com o Picnik), offline o máximo que dá pra fazer é usar o teclado no Quick Office. Preciso de mais que isso.
Por isso aproveitei o fim de ano para um projetinho divertido: transformar o Atrix com Lapdock em algo mais parecido com um “netbook”, com as ferramentas necessárias para me ser útil mesmo quando estou offline. Isso é fácil de fazer e você sequer precisa de ROMs customizadas: bastam alguns minutos e um cartão microSD. O resultado é um “netbook” Ubuntu, onde você pode instalar e rodar o que quiser.
Há alguns dias desbloqueei meu Nexus S e comecei a experimentar ROMs com versões customizadas do sistema operacional Android. A primeira parada foi a popular CyanogenMod 7 (versão RC2), baseada no Android 2.3.3. Mas logo mudei de idéia quando soube que havia sido lançada uma versão beta da MIUI ROM.
A MIUI é uma ROM desenvolvida na China – também baseada no Android 2.3.3 – que se destaca por ter uma interface bastante diferente do Android padrão, que pode ser descrita como uma mistura do iOS da Apple com o sistema do Google. Não é uma “skin de iPhone” para Android, é uma mistura de conceitos das duas plataformas, com resultado bastante interessante.
