Ceticismo: o notebook de duas telas da Acer está chegando ao mercado

Já faz algum tempo que diversos fabricantes estão apresentando protótipos de notebooks com duas telas, mas ao que tudo indica a Acer será a primeira a dar a cara a tapa e colocar um desses monstrinhos no mercado, com o Iconia:

Ele usa duas telas de 14" (1366x768), ambas com touchscreen capacitivo e vidro gorilla, fazendo com que ele seja uma espécie de elo perdido entre o notebook e o tablet. Ao ler, a segunda tela serve como uma extensão da primeira, exibindo mais da página e ao colocar as mãos para digitar (é preciso tocar a tela com cinco dedos simultaneamente) ele mostra automaticamente um teclado virtual.

Em outras situações, a segunda tela pode ser usada para outras funções, como por exemplo exibir a galeria de mídia, enquanto a tela principal continua sendo usada para visualizar outro conteúdo:

Em outras palavras, a Acer está tentando fazer com que a segunda tela do Iconia tenha mais utilidade do que como um simples touchscreen, resta saber até que ponto terão sucesso.

Apesar da aparência dos screenshots, ele não roda o Android ou outro sistema para teblets, mas sim o Windows 7, impulsionado por um processador Core i5 i5-480M/560M/580M, até 4GB de memória DDR3, HD magnético de até 750 GB, USB 3.0, webcam, Wi-Fi 802.11n, Bluetooth, 3G e um peso total de 3 kg. A Acer desenvolveu um novo shell para o sistema, que oferece uma interface mais utilizável, mas resta saber até que ponto isso se estende a outros softwares.

A Acer ainda não divulgou o preço, mas calculando o preço de duas telas resistivas de 14" e do restante do hardware, combinado com o "hipe-factor", me parece improvável que o monstrinho custe menos de US$ 1000 no mercado norte-americano. Em outras palavras, é uma compra de altíssimo risco, considerando a combinação de potenciais limitações com um preço tão alto.

Embora os fabricantes vejam o conceito como uma oportunidade de atrair a atenção do público, continuo veemente cético em relação aos notebooks de duas telas. Eles substituem um par de componentes baratos e que funcionam muito bem (teclado e touchscreen) por um componente muito mais caro (a segunda tela) e que não cumpre bem a função do primeiro. Eles não são uma boa ideia nem mesmo como leitores de e-books e revistas, já que o peso torna desconfortável de segurá-los, sem falar das inconsistência de tentar rodar o Windows 7 em um dispositivo que usa exclusivamente um par de touchscreens como dispositivos de entrada.

O engadget publicou um vídeo mostrando o uso da segunda tela, que revela várias possibilidades interessantes, mas eu ainda não estou convencido:

Relacionados

Acer

Redes: TCP/IP, endereçamento e portas

O endereçamento IP é sempre um tema importante, já que é ele que permite que o brutal número de redes e hosts que formam a Internet sejam capazes de se comunicar entre si.

Existem duas versões do protocolo IP: o IPV4 é a versão atual, que utilizamos na grande maioria das situações, enquanto o IPV6 é a versão atualizada, que prevê um número brutalmente maior de endereços e deve se popularizar a partir de 2012 ou 2014, quando os endereços IPV4 começarem a se esgotar.

No IPV4, os endereços IP são compostos por 4 blocos de 8 bits (32 bits no total), que são representados através de números de 0 a 255 (cobrindo as 256 possibilidades permitidas por 8 bits), como "200.156.23.43" ou "64.245.32.11". Os grupos de 8 bits que formam o endereço são chamados de "octetos", o que dá origem a expressões como "o primeiro octeto do endereço". De qualquer forma, a divisão dos endereços em octetos e o uso de números decimais serve apenas para facilitar a configuração para nós, seres humanos. Quando processados, os endereços são transformados em binários, como "11001000100110010001011100101011".

As faixas de endereços começadas com "10", "192.168" ou de "172.16" até "172.31" são reservadas para uso em redes locais e por isso não são usadas na Internet. Os roteadores que compõe a grande rede são configurados para ignorar pacotes provenientes destas faixas de endereços, de forma que as inúmeras redes locais que utilizam endereços na faixa "192.168.0.x" (por exemplo) podem conviver pacificamente, sem entrar em conflito.

No caso dos endereços válidos na Internet, as regras são mais estritas. A entidade global responsável pelo registro e atribuição dos endereços é a IANA (http://www.iana.org/), que delega faixas de endereços às RIRs (Regional Internet Registries), entidades menores, que ficam responsáveis por delegar os endereços regionalmente. Nos EUA, por exemplo, a entidade responsável é a ARIN (http://www.arin.net/) e no Brasil é a LACNIC (http://www.lacnic.net/pt/). Estas entidades são diferentes das responsáveis pelo registro de domínios, como o Registro.br.

As operadoras, carriers e provedores de acesso pagam uma taxa anual à RIR responsável, que varia de US$ 1.250 a US$ 18.000 (de acordo com o volume de endereços requisitados) e embutem o custo nos links revendidos aos clientes. Note que estes valores são apenas as taxas pelo uso dos endereços, não incluem o custo dos links, naturalmente.

Ao conectar via ADSL ou outra modalidade de acesso doméstico, você recebe um único IP válido. Ao alugar um servidor dedicado você recebe uma faixa com 5 ou mais endereços e, ao alugar um link empresarial você pode conseguir uma faixa de classe C inteira. Mas, de qualquer forma, os endereços são definidos "de cima para baixo" de acordo com o plano ou serviço contratado e você não pode escolher quais endereços utilizar.

Embora aparentem ser uma coisa só, os endereços IP incluem duas informações: o endereço da rede e o endereço do host dentro dela. Em uma rede doméstica, por exemplo, você poderia utilizar os endereços "192.168.1.1", "192.168.1.2" e "192.168.1.3", onde o "192.168.1." é o endereço da rede (e por isso não muda) e o último número (1, 2 e 3) identifica os três micros que fazem parte dela.

Os micros da rede local podem acessar a Internet através de um roteador, que pode ser tanto um servidor com duas placas de rede quando um modem ADSL ou outro dispositivo que ofereça a opção de compartilhar a conexão. Nesse caso, o roteador passa a ser o gateway da rede e utiliza seu endereço IP válido para encaminhar as requisições feitas pelos micros da rede interna. Esse recurso é chamado de NAT (Network Address Translation).

Um dos micros da rede local, neste caso, poderia usar esta configuração de rede:

• Endereço IP: 192.168.1.2
• Máscara: 255.255.255.0
• Gateway: 192.168.1.1 (o servidor compartilhando a conexão)
• DNS: 200.169.126.15 (o DNS do provedor)

O servidor, por sua vez, utilizaria uma configuração similar a esta:

• Placa de rede 1 (rede local):
• Endereço IP: 192.168.1.1
• Máscara: 255.255.255.0
• Placa de rede 2 (Internet):
• Endereço IP: 200.213.34.21
• Máscara: 255.255.255.0
• Gateway: 200.213.34.1 (o gateway do provedor)
• DNS: 200.169.126.15 (o DNS do provedor)

A configuração da segunda placa de rede seria obtida automaticamente, via DHCP, de forma que você só precisaria realmente se preocupar com a configuração da sua rede local. Normalmente, você primeiro configuraria a rede local, depois conectaria o servidor à Internet e, depois de checar as duas coisas, ativaria o compartilhamento da conexão via NAT.

O servidor DHCP incluído no ICS do Windows utiliza uma configuração fixa, fornecendo endereços dentro da faixa "192.168.0.x", mas ao utilizar um servidor Linux, ou qualquer outro dispositivo de rede que ofereça um servidor DHCP com mais recursos, você pode escolher qualquer faixa de endereços e também configurar uma "zona" para os endereços do servidor DHCP, permitindo que você tenha micros com IPs fixos e IPs dinâmicos (fornecidos pelo servidor DHCP) na mesma rede. Nesse caso, você poderia ter uma configuração como a seguinte:

• 192.168.0.1: Gateway da rede
• 192.168.0.2: Ponto de acesso wireless
• 192.168.0.3: Servidor de arquivos para a rede interna
• 192.168.0.4 até 192.168.0.99: Micros da rede configurados com IP fixo
• 192.168.0.100 até 192.168.0.254: Faixa de endereços atribuída pelo servidor DHCP

Veja que usar uma das faixas de endereços reservadas não impede que os PCs da sua rede possam acessar a Internet. Embora eles não acessem diretamente, por não possuírem IPs válidos, eles podem acessar através de uma conexão compartilhada via NAT ou de um servidor proxy. É possível, inclusive, configurar o firewall ativo no gateway da rede para redirecionar portas (port forwarding) para micros dentro da rede local, de forma que eles possam ser acessados remotamente. O servidor nesse caso "empresta" uma porta, ou uma determinada faixa de portas, para o endereço especificado dentro da rede local. Quando alguém da Internet acessa uma das portas encaminhadas no servidor, é automaticamente redirecionado para a porta correspondente no micro da rede interna, de forma transparente.

O uso dos endereços de rede local tem aliviado muito o problema da falta de endereços IP válidos, pois uma quantidade enorme de empresas e usuários domésticos, que originalmente precisariam de uma faixa de endereços completa para colocar todos os seus micros na Internet, pode sobreviver com um único IP válido (compartilhado via NAT entre todos os micros da rede). Em muitos casos, mesmo provedores de acesso chegam a vender conexões com endereços de rede interna nos planos mais baratos, como, por exemplo, alguns planos de acesso via rádio, onde um roteador com um IP válido distribui endereços de rede interna (conexão compartilhada) para os assinantes.

Embora seja possível, pelo menos em teoria, ter redes com até 24 milhões de PCs, usando a faixa de endereços de rede local 10.x.x.x, na prática é raro encontrar segmentos de rede com mais de 100 ou 200 micros. Conforme a rede cresce, o desempenho acaba caindo, pois, mesmo ao utilizar um switch, sempre são transmitidos alguns pacotes de broadcast (que são retransmitidos a todos os micros do segmento). A solução nesse caso é dividir a rede em segmentos separados, interligados por um roteador.

Em uma empresa, poderíamos (por exemplo) ter três segmentos diferentes, um para a rede cabeada (e a maior parte dos micros), outro para a rede wireless e outro para os servidores, que ficariam isolados em uma sala trancada:

O roteador nesse caso teria 4 interfaces de rede (uma para cada um dos três segmentos e outra para a Internet). A vantagem de dividir a rede desta maneira é que você poderia criar regras de firewall no roteador, especificando regras diferentes para cada segmento. Os micros conectados à rede wireless (menos segura), poderiam não ter acesso aos servidores, por exemplo. Quando falo em "roteador", tenha em mente que você pode perfeitamente usar um servidor Linux com diversas placas de rede.

Com relação à proteção da rede contra acessos provenientes da Internet, você poderia tanto configurar o próprio firewall ativo no roteador, de forma a proteger os micros da rede local quanto instalar um firewall dedicado (que pode ser um PC com duas placas de rede, configurado adequadamente) entre ele e a Internet

A vida curta e os tempos difíceis de um vírus de Linux

Derivado para o Português por Pedro A. D. Rezende do artigo publicado em Librenix por Ray Yargin:
 

Por que é que vírus de Linux não é mais do que um assunto para rodas de ciberpapo? Por que é que os vírus para Linux não nos afetam do jeito que os vírus para produtos Microsoft afetam, a usuários do Windows em particular, e aos cibernautas em geral?

Existem várias razões porque o assunto vírus-de-Linux é abobrinha. Quase todas elas já familiares para quem usa o kernel, quase todas elas ainda desprezadas por quem gosta de ser enganado (tagarelando abobrinhas tipo "é menos atacado porque é menos usado"). Mas há uma razão, muito importante, que estudiosos da evolução biológica podem apreciar. Antes, porém, devemos saber porque o Linux não dá mole para vírus.

Para que um vírus infecte um programa executável num sistema com kernel Linux, numa distro GNU/Linux (Debian, Slackware, RedHat, Suse, Ubuntu, Kurumin, Mandriva, etc.) por exemplo, o executável precisa estar em arquivo com permissão de escrita para o usuário que esteja ativando o vírus. Tal situação é incomum. Numa instalação desktop, via de regra os arquivos executáveis têm como dono (owner) o administrador do sistema (root), e rodam em processo de usuário comum. Ou seja, a partir de uma conta não-privilegiada.

Além do que, quanto menos experiente for o usuário, menos provável que tenha ele mesmo feito a instalação do executável, e portanto, que seja o owner do arquivo correspondente. Assim, os usuários de Linux que menos entendem dos perigos de infecção viral são os que têm pastas pessoais (diretório home) menos férteis para isso.

Prosseguindo, ainda que um vírus consiga infectar um programa executável, sua missão de proliferar-se esbarra em dificuldades das quais os limites nas permissões do dono do arquivo infectado são apenas o começo (para neófitos, em sistemas com um só usuário, esses limites podem desaparecer se a conta root for usada descuidadamente). As dificuldades continuam nos programas para conectividade, por serem esses no Linux construídos conservadoramente, sem os recursos de macros em alto nível que têm permitido, por exemplo, a recentes vírus de Windows propagarem-se tão rapidamente.

Esse conservadorismo não é uma característica do Linux, mas reflete diretamente importantes diferenças na base de usuários de plataformas livres e proprietárias. Diferenças na forma como essas bases atuam no processo de desenvolvimento, e na forma como a robustez e a popularidade dos programas é afetada por essa atuação, através dos respectivos modelos de licença e de negócio. Na forma, por exemplo, em que vacinas atuam. As lições aprendidas pela observação do que acontece no outro modelo servem, no modelo colaborativo, para vacinar não o software em si, mas o processo e a estratégia de desenvolvimento dos softwares livres, livres inclusive das estratégias de negócio de interessados que lhes sejam confiltantes.

Aplicativos e sistemas baseados em Linux são quase todos de código fonte aberto. Devido à quase totalidade desse mercado estar acostumado à disponibilidade do código-fonte, produtos distribuídos apenas em formato executável são ali raros, e encontram mais dificuldade para firmar presença. Isso tem dois efeitos no ecosistema viral, se considerarmos que a propagação ocorre em formato executável. Primeiro, programas com código fonte aberto são lugares difíceis para vírus se esconderem. Segundo, a (re)instalação por compilação do código-fonte corta completamente um dos principais vetores de propagação dos vírus.

Cada um desses obstáculos representa uma barreira significativa. Porém, é quando essas barreiras atuam em conjunto que a vida do vírus se complica. Um vírus de computador, da mesma forma que o biológico, precisa de uma taxa de reprodução maior do que a taxa de erradicação (morte), para se proliferar. Na plataforma Linux, cada um desses obstáculos reduz significativamente a taxa de reprodução. E se a taxa de reprodução cai abaixo do nível necessário para substituir a população erradicada, o vírus está condenado à extinção, nesse ambiente -- mesmo antes das notícias alarmistas sobre o potencial de dano às vítimas.

A razão pela qual nunca vimos uma epidemia de verdade com vírus de Linux é simplesmente porque nenhum vírus conseguiu, até hoje, prosperar no ambiente que o Linux propicia. Os que já surgiram com esse alvo não são mais do que curiosidades técnicas (Staog foi o primeiro deles, e o único observado à solta, até 2005, foi o Bliss). A realidade é que não existe vírus viável para Linux.

Isso, é claro, não significa que nunca possa haver uma epidemia viral envolvendo o Linux. Por outro lado, isso significa que o vírus precisaria ser muito inovador e bem arquitetado para ter sucesso prosperando nesse ecosistema (do Linux), que é hostil para código furtivo. E também, que outros especialistas possam entender a questão de maneira diferente (para outra perspectiva sobre o tema, tente esse artigo).