Lomadee, uma nova espécie na web. A maior plataforma de afiliados da América Latina.

domingo, 2 de janeiro de 2011

Uma breve história do Linux

 Introdução


    O sistema operacional é o responsável por ativar todos os periféricos e criar o ambiente sobre o qual todos os outros programas rodam. É ele o responsável por reservar processamento suficiente para que o MP3 que você está ouvindo em background continue sendo tocado mesmo quando você precisa abrir outro aplicativo pesado, ou por transferir programas e bibliotecas sem uso para a memória virtual quando a memória principal está quase toda ocupada, por exemplo. Isso faz com que o trabalho do sistema operacional seja uma atividade inglória, já que você só se lembra dele quando alguma coisa dá errado. :)
    Para tristeza de alguns e alegria de outros, o Windows é o sistema operacional mais usado em desktops, o que faz com que ele seja a plataforma mais familiar para a maioria. Muitas tarefas são complicadas (experimente tentar encontrar drivers para alguma placa-mãe antiga, por exemplo), mas, como muita gente usa e muitos passam pelos mesmos problemas, acaba existindo uma rede de suporte em torno do sistema.
    O domínio da Microsoft na área de sistemas operacionais começou em 1981, com o lançamento do primeiro PC e da primeira versão do MS-DOS. Embora não tivesse nada de especial com relação a outros sistemas da época, o DOS cresceu em popularidade junto com os PCs, seguido pelas diversas versões do Windows. Apesar disso, a Microsoft é uma página recente na história da informática. Enquanto o MS-DOS ainda dava seus primeiros passos, o Unix já era um sistema maduro, usado na maioria dos computadores de grande porte e em estações de trabalho. A história do Unix começou em 1969, na frente de um computador igual a este:
    Este é um PDP-7, um "minicomputador" da década de 1960 que possuía apenas 8 kbytes de memória RAM e utilizava fitas magnéticas para o armazenamento de dados. Hoje em dia, qualquer agenda eletrônica ou celular possui muito mais memória e poder de processamento do que ele, mas na época era um equipamento relativamente poderoso, que custava US$ 72.000.
    Devido às pesadas limitações da máquina, o sistema operacional deveria ser extremamente enxuto e otimizado, de forma a extrair o máximo de desempenho e consumir o mínimo possível de memória. A combinação da criatividade dos desenvolvedores, a necessidade e as limitações impostas pelo equipamento, resultou em um sistema bastante otimizado e elegante. Muitas das idéias surgidas nessa época continuam sendo usadas até hoje.
    O Unix evoluiu durante a década de 1970, passando a ser usado em cada vez mais equipamentos e ganhando mais recursos. Quase sempre ele era usado em aplicações "sérias", incluindo instalações militares, bancos e outras áreas onde não existe margem para falhas. Devido a tudo isso, o sistema se tornou muito robusto e estável.
    Os primeiros sistemas Unix foram desenvolvidos de forma colaborativa, dentro de universidades e centros de pesquisa. Embora naquela época ainda não existisse a Internet como a conhecemos hoje, existia uma grande colaboração entre os desenvolvedores. Isso mudou na década de 1980, quando empresas como a AT&T, Sun e SCO, que detinham os direitos sobre o sistema, passaram a desenvolver versões proprietárias e a concorrerem entre si. A colaboração deixou de acontecer e a plataforma foi fragmentada em versões incompatíveis.
    Outro fator importante foi a falta de investimento em versões destinadas a micros PCs. Na época, os PCs eram vistos como computadores muito limitados, incapazes de rodar sistemas Unix completos (lembre-se de que estou falando do início da década de 1980, quando ainda eram usados micros XT e 286). Somados, estes dois fatores fizeram com que a plataforma definhasse, deixando o caminho livre para o crescimento da Microsoft e das diferentes versões do Windows. Chegamos, então, ao Linux.
    Tudo começou em 1991, quando Linus Torvalds começou a trabalhar no desenvolvimento de um sistema Unix para rodar em seu 386. Na época, o único sistema similar era o Minix, um sistema operacional para uso acadêmico, que era bastante limitado. No início, Linus usava o Minix para rodar o editor, compiladores e outras ferramentas de desenvolvimento que utilizava para desenvolver o kernel Linux, mas, a partir de um certo ponto, ele passou a usar o próprio Linux. Ou seja, depois de um breve período de encubação dentro do Minix, o Linux passou a ser desenvolvido dentro do próprio Linux. :)
    De início, o kernel Linux era um projeto muito pequeno, o hobby de um único programador. Entretanto, ele tinha uma grande vantagem em relação aos sistemas UNIX que o precederam: o simples fato de ser disponibilizado sob a licença GPL. Isso permitiu que outros programadores adotassem o projeto, passando a contribuir com melhorias e correções. Subitamente, toda a demanda acumulada em relação a um sistema Unix para micros PC foi canalizada em torno do Linux, fazendo com que o sistema passasse a crescer em um ritmo cada vez mais acelerado, chegando ao que temos nos dias de hoje.
    A licença GPL, tão comentada, mas ao mesmo tempo tão mal-compreendida, pode ser resumida em 4 direitos básicos e uma obrigação:
    1- Aplicativos disponibilizados sob a GPL podem ser usados por qualquer um e para qualquer fim, sem limitações. Mesmo que eventualmente os criadores mudem de ideia e resolvam passar a distribuir novas versões do programa sob outra licença, as versões que foram distribuídas sob a GPL continuam disponíveis, o que permite que outros desenvolvedores criem uma derivação e continuem o desenvolvimento. Isso traz uma boa dose de segurança para quem usa o aplicativo, já que reduz a chance de ele ser descontinuado e ficar indisponível. Enquanto houver um volume considerável de usuários interessados no aplicativo, é bem provável que o desenvolvimento continue, de uma forma ou de outra.
    2- Direito de tirar cópias do programa, distribuí-las ou até mesmo vendê-las a quem tiver interesse. Existe a possibilidade de ganhar algum dinheiro vendendo CDs gravados, por exemplo, mas como todo mundo pode fazer a mesma coisa, é preciso vender por um preço relativamente baixo, cobrando pelo trabalho de gravação e não pelo software em si, que está largamente disponível.
    Isso faz com que a forma mais eficiente de ganhar dinheiro com os softwares seja prestar suporte e vender serviços de personalização e não com a venda direta, como no caso dos softwares comerciais. Para o cliente, acaba sendo vantajoso, pois o custo de implantação será o gasto com a consultoria e treinamentos, enquanto ao implantar um software comercial qualquer, ele gastaria também com as licenças de uso.
    3- Direito de ter acesso ao código fonte do programa, fazer alterações e redistribuí-las. Para um programador este é o principal atrativo, já que permite criar novos projetos usando como base o código fonte de programas já existentes (ao invés de ter sempre que começar do zero), sem falar na grande oportunidade de aprendizado que examinar o código fonte de outros programas propicia.
    4- Direito (e ao mesmo tempo a obrigação) de redistribuir as modificações feitas. Este é o ponto onde existem mais mal-entendidos. Se você desenvolve um software por hobby, ou para usá-lo internamente na sua empresa, e não possui interesse em explorá-lo comercialmente, você pode simplesmente divulgar o código fonte para todo mundo, o que é o caminho mais lógico se você pretende atrair outros interessados em ajudá-lo no desenvolvimento. Mas, caso você pretenda receber pelo seu trabalho de desenvolvimento, existem duas opções:
    a) Você pode distribuir o software livremente para aumentar a base de usuários e ganhar vendendo suporte, treinamentos e personalizações.
    b) Você só é obrigado a distribuir o código fonte a quem obtém o software, de forma que você pode trabalhar batendo de porta em porta, vendendo o software para alguns clientes específicos e fornecendo o código fonte apenas para eles. Não existe nada de errado com este modelo, mas você perde a possibilidade de ter contribuições de outros desenvolvedores, o que pode ser ruim a longo prazo.
    Os softwares distribuídos sob a GPL também não "contaminam" softwares comerciais ou de outras licenças no caso de distribuição conjunta. Por exemplo, uma revista pode distribuir alguns softwares GPL no meio de um monte de aplicativos proprietários na mesma edição. Os softwares GPL continuam sendo GPL, com todas regras que vimos acima, enquanto os softwares proprietários continuam sendo fechados. A revista deve incluir o código fonte dos aplicativos GPL (ou pelo menos a informação de como obtê-los via Internet) mas, naturalmente, não precisa fazer o mesmo com os outros aplicativos incluídos no CD.
    Você pode também usar algum software GPL em conjunto com o seu aplicativo comercial, desenvolvendo um aplicativo qualquer que utiliza o Postgree SQL (um servidor de banco de dados), por exemplo. O Postgree SQL continua sendo GPL e o seu aplicativo continua sendo fechado; qualquer um pode usar e tirar cópias do Postgree SQL, mas você controla a distribuição do seu aplicativo. Uma coisa não interfere com a outra.
    Ou seja, muito embora alguns vejam a GPL como algum tipo de licença comunista, que diz que todos os programadores devem fazer voto de miséria e passar a trabalhar de graça em nome do bem comum, ela é na verdade apenas uma licença que estimula a colaboração e o reaproveitamento de softwares e componentes, e que vem nos trazendo diversas mudanças positivas. De certa forma, podemos dizer que a GPL é uma licença até bastante capitalista (no bom sentido), pois estimula a concorrência entre projetos e empresas e dificulta a criação de monopólios, que são ruins para o sistema econômico.
    Voltando à história, embora o kernel seja o componente mais importante do sistema (e também o mais complexo), ele não é o único. Qualquer sistema operacional moderno é a combinação de um enorme conjunto de drivers, bibliotecas, aplicativos e outros componentes. O kernel é apenas uma base sobre a qual todos eles rodam.
    Além do período de incubação dentro do Minix, o Linux se beneficiou de diversos outros projetos anteriores, tais como o X (responsável pela interface gráfica) e inúmeros utilitários, bibliotecas, linguagens de programação, compiladores e assim por diante. A eles se soma uma grande lista de interfaces e aplicativos que surgiram nos anos seguintes, tais como o GNOME, o KDE, o Firefox e o OpenOffice.
    Entre as ferramentas usadas desde os primeiros dias, estão o Emacs e o GCC, desenvolvidos pela Free Software Fundation, como parte do projeto GNU. O Emacs é um editor de texto que combina uma grande quantidade de recursos e ferramentas úteis para programadores, enquanto o GCC é o compilador que permite transformar o código escrito nele em arquivos executáveis.
    Isso deu origem a uma das maiores flame-wars da história da informática, com Richard Stallman passando a exigir o uso do termo "GNU/Linux" (que é pronunciado como "guí-nuu issléchi Linux") para designar o sistema, em vez de simplesmente "Linux", argumentando que o projeto GNU foi iniciado antes e que por isso merece crédito.
    Este é um caso em que as opiniões se dividem, com alguns dando razão à ele e realmente usando o "guí-nuu issléchi Linux" (ou "guínû barra Linux", que é a versão aportuguesada), e outros argumentando que os componentes do projeto GNU correspondem a apenas uma pequena parte do sistema e que por isso se fosse para dar o crédito devido a todos os inúmeros componentes que formam uma distribuição atual, seria preciso chamar o sistema de X/Qt/KDE/GTK/GNOME/Mozilla/Firefox/OpenOffice/...longa-lista.../GNU/Linux.
    O fato é que, excluindo qualquer discussão filosófica, o nome "Linux" puro e simples é muito mais fácil de pronunciar, o que faz com que o "GNU/Linux" não seja usado fora de alguns círculos específicos.
    Continuando a história, embora o Linux tenha sido originalmente desenvolvido para ser usado em micros PC (mais especificamente no 386 que Linus Torvalds usava em 1991), a modularidade do sistema, o fato de ele ter sido escrito inteiramente em C e as boas práticas empregadas no desenvolvimento permitiram que ele ganhasse versões (ou ports) para outras plataformas. Hoje em dia, o Linux roda em praticamente todo o tipo de sistemas: de PCs domésticos equipados com chips de 32 ou 64 bits, a equipamentos especializados, usados em maquinário industrial.
    Existe até mesmo um fork do kernel Linux que é capaz de rodar em processadores 8088 e 286 (o ELKS), como os usados nos primeiros micros PC. Embora estejam obsoletos nos PCs a mais de duas décadas, versões modernizadas desses chips são relativamente populares em sistemas embarcados, concorrendo com chips Z80 e outros processadores de 8 ou 16 bits, que, embora desconhecidos do grande publico, são produzidos e usados em quantidades gigantescas nos mais diversos tipos de dispositivos. É justamente essa versatilidade que faz com que o Linux seja usado em tantas áreas diferentes, de celulares a supercomputadores.
    Ao ver micros com Linux em exposição nas lojas e em mercados, tenha em mente que esta é apenas a ponta do iceberg. O uso do Linux em micros domésticos, pelo grande público, é uma coisa relativamente recente. Antes de chegar aos desktops, o Linux cresceu entre os desenvolvedores e usuários avançados, dominou os servidores, invadiu o mundo dos dispositivos embarcados (celulares, roteadores, pontos de acesso wireless e até mesmo modems ADSL) e se tornou o sistema dominante no mundo dos supercomputadores.
    Segundo o http://www.top500.org/ (que mantém um rank atualizado dos 500 supercomputadores mais poderosos do mundo), em novembro de 2008 nada menos do que 439 dos 500 supercomputadores mais poderosos rodavam diferentes versões do Linux (http://www.top500.org/stats/list/32/osfam). Dos restantes, 25 rodavam outros sistemas Unix e apenas 5 rodavam Windows, um deles com o HPC Server 2008 e quatro com o Windows Computer Cluster Server 2003, duas versões do Windows especialmente otimizadas para a tarefa.
    Como baixar, gravar e dar boot

      A forma mais popular de disponibilizar novas versões das distribuições é através de arquivos ISO, cópias binárias do conteúdo dos CDs ou DVDs de instalação, que você pode gravar usando o Nero, K3B ou outro programa de gravação, obtendo um CD idêntico ao original.
      Um dos sites mais conhecidos com notícias sobre os lançamentos de novas versões e links para baixar até mesmo as distribuições menos conhecidas é o http://distrowatch.com/, que além dos links e notícias, mantém um abrangente banco de dados sobre as distribuições Linux ativas e também as inativas ou descontinuadas.
      Como pode imaginar, disponibilizar ISOs de distribuições Linux para download exige muita banda, o que faz com que muitos desenvolvedores incentivem o download dos arquivos via bittorrent. Apesar disso, existem diversos mirrors públicos que oferecem as imagens para download direto, a maioria deles situados em universidades ou empresas de hospedagem. Alguns links de mirrors nacionais, onde você pode fazer um download rápido são:
      Quase sempre, você tem a opção de baixar a versão "x86" (que corresponde à versão tradicional, destinada a máquinas com processadores de 32 bits) e a versão "x86-64", que é a versão compilada para tirar proveito das instruções de 64 bits suportadas pelos processadores atuais.
      De uma forma geral, as versões de 32 bits são menos problemáticas, pois você pode simplesmente instalar qualquer aplicativo, biblioteca ou plugin sem precisar se preocupar em procurar uma versão de 64 bits do pacote. Mesmo que seu micro seja baseado em um processador Core 2 Duo, Athlon X2 ou outro processador de 64 bits, o uso das versões de 64 bits do sistema é inteiramente opcional, o que faz com que muitos prefiram simplesmente continuar usando as versões de 32 bits.
      Ao contrário do que muitos pensam, usar um sistema de 64 bits nem sempre resulta em ganhos de desempenho. Pelo contrário, na maioria das vezes o desempenho acaba sendo inferior, pois o pequeno ganho derivado do uso das instruções de 64 bits e dos novos registradores acaba sendo negado pelo uso de endereços de 64 bits (que consomem mais memória) e pela necessidade de duplicar bibliotecas e outros componentes do sistema, o que é feito sempre que é preciso rodar binários de 32 bits dentro de um chroot em uma distribuição compilada para usar processadores de 64 bits.
      A grande vantagem de utilizar um sistema de 64 bits não é necessariamente o desempenho, mas sim o suporte a mais de 3 GB de memória RAM. Todos os processadores de 32 bits possuem um limite "físico" de endereçamento, que limita a memória RAM suportada a um máximo de 4 GB. Destes, 1 GB é sacrificado para endereçamento dos dispositivos (veja mais detalhes no capítulo 4 do livro Hardware, o Guia Definitivo), o que, na prática, restringe o sistema a um máximo de 3 GB de memória RAM.
      Com isso, a decisão entre usar uma distribuição de 32 bits ou de 64 bits se resume à quantidade de memória RAM que você pretende utilizar. Se seu PC tem até 3 GB de memória e você não quer esquentar a cabeça com problemas e incompatibilidades, o mais fácil é simplesmente usar a versão de 32 bits. Se, por outro lado, seu micro tem 4 GB ou mais de memória e você pretende que toda a memória seja realmente utilizada, então sua única opção é usar a versão de 64 bits.
      Voltando ao básico, gravar um arquivo ISO é diferente de gravar um arquivo qualquer no CD. Um arquivo ISO é uma imagem binária que deve ser gravada bit a bit na mídia, e não simplesmente adicionado dentro de uma nova seção.
      Ao usar o K3B, por exemplo, clique no "Ferramentas > Queimar imagem de CD" (ou "Ferramentas > Queimar imagem ISO de DVD"), aponte o arquivo, escolha a velocidade de gravação e clique em "Gravar". Marque a opção "Verificar dados gravados"; ela verifica a mídia depois de concluída a gravação, avisando sobre erros de gravação:
      Com o CD ou DVD gravado, falta apenas configurar o setup do micro para dar boot através dele. A maioria dos micros vêm configurados para dar boot preferencialmente através do CD-ROM. Nesse caso, basta deixar o CD na bandeja e você já cai na tela de boas-vindas do sistema. Se não for o seu caso, pressione a tecla DEL, F1 ou F2 (dependendo do fabricante) para acessar o Setup. Procure pela seção "Boot" e coloque o CD-ROM como dispositivo primário. Feito isso, é só salvar a configuração usando a opção "Save & Exit setup".
      Ao reiniciar o micro sem o CD no drive, ele volta a carregar o Windows ou outro sistema que estiver instalado no HD. Esta alteração apenas faz com que ele passe a procurar o sistema primeiro no CD-ROM.
      Um hábito saudável é verificar a integridade do arquivo ISO antes de gravar o CD. Sempre é possível que o arquivo esteja incompleto, ou venha corrompido por problemas com a conexão ou no gerenciador de downloads usado. Você pode detectar este tipo de problema (e evitar gastar mídias à toa) verificando o MD5SUM do ISO antes de gravar. Ele é um teste que soma todos os bits do arquivo e devolve uma "assinatura", um código de 32 dígitos que permite detectar qualquer mudança no arquivo.
      Os códigos de assinatura dos arquivos estão quase sempre disponíveis na página de download, como em:
      ed6a5b3feb668866df812b1c2aed9d7f  openSUSE-11.0-DVD-i386.iso
      Você precisa apenas rodar o MD5SUM no arquivo baixado e ver se o resultado é igual ao número da página. No Linux (qualquer distribuição), acesse a pasta onde o arquivo foi baixado e digite:
      $ md5sum openSUSE-11.0-DVD-i386.iso
      No Windows, baixe o programa disponível no http://www.md5summer.org/download.html, que é uma versão gráfica do utilitário.
      Sempre que o arquivo estiver corrompido ou incompleto, o resultado do MD5SUM é diferente, o que permite detectar o problema. O MD5SUM é bastante sensível; a alteração de alguns poucos bits dentro do arquivo é suficiente para alterar completamente o resultado.
      Outra dica é que você pode reparar downloads corrompidos usando o bittorrent de forma bastante simples. Procure o link para baixar o ISO via bittorrent e salve-o na mesma pasta onde está o arquivo corrompido. Ao iniciar o download, o cliente bittorrent detectará o arquivo e tentará continuar o download. Como o bittorrent trabalha baixando os arquivos em pedaços e verificando cada parte de forma independente, ele será capaz de reparar o arquivo, baixando apenas as partes danificadas, evitando que você precise baixar todo o arquivo novamente.
      Caso ele crie uma pasta com um arquivo vazio, basta fechar o programa, mover o arquivo ISO para dentro da pasta (substituindo o arquivo vazio) e começar de novo.
      Concluindo, embora os CDs e DVDs ainda sejam as mídias de instalação preferidas pela maioria, eles estão gradualmente perdendo espaço para os pendrives, que acabam sendo mais práticos em muitas situações, sobretudo no caso dos netbooks, que abandonam o uso do drive óptico em favor da portabilidade.
      Muitas distribuições, incluindo o Ubuntu e o Fedora, já oferecem utilitários gráficos que permitem gerar um pendrive bootável (no Ubuntu, por exemplo, você usaria o "Sistema > Administração > Create a USB startup disk") e, para as demais, está disponível o UNetbootin, um pequeno utilitário que permite gerar um pendrive bootável a partir do arquivo ISO do CD:
      Ele possui versões para Linux e para Windows e está disponível no: http://unetbootin.sourceforge.net/
      Ele ainda não é compatível com todas as distribuições, mas a lista está crescendo rapidamente. Se você utiliza uma conexão de banda larga, existe também a opção de usar uma das opções de instalação via rede, onde ele copia apenas uma pequena imagem de boot para o pendrive e o resto do sistema é baixado através da rede ao iniciar a instalação.
      Rodando o Linux, sem sair do Windows

        Se, assim como a maioria, você possui um único PC ou notebook, uma opção para testar as distribuições Linux sem precisar mexer no particionamento do HD e instalar o sistema em dual-boot, é simplesmente rodar o sistema dentro de uma máquina virtual (VM), no próprio Windows.
        Com isso, você ganha liberdade para testar o sistema, fuçar nas configurações, instalar e remover programas e assim por diante, sem precisar se preocupar em deixar seu PC fora de operação. Uma máquina virtual nada mais é do que um conjunto de arquivos dentro de uma pasta do HD, de forma que se algo dá errado, você só tem o trabalho de deletar a pasta e começar de novo.
        Naturalmente, você pode também fazer o contrário, ou seja, rodar uma distribuição Linux como sistema primário e instalar o Windows dentro de uma máquina virtual para tê-lo a disposição sempre que precisar de algum programa específico, como veremos ao longo do livro.
        As possibilidades são quase ilimitadas. Você pode testar diversas distribuições Linux; ter um sistema de backup para navegar e instalar programas, sem o risco de danificar o sistema principal; instalar o Ubuntu, Mandriva, OpenSuSE, Debian, Fedora ou outras distribuições sem precisar mexer no particionamento do HD; e assim por diante. Usar uma VM é a forma mais prática de ter Windows e Linux na mesma máquina, pois você pode usar os dois sistemas lado a lado.
        Existem vários softwares de virtualização gratuitos para Windows, incluindo versões do VMware e do VirtualBox, mas, para começar, recomendo o VMware Player, que é uma opção bastante prática e fácil de usar. Você pode baixá-lo nohttp://vmware.com/download/player/ ou diretamente no: http://www.vmware.com/download/player/download.html
        As versões da série 2.x são relativamente grandes (o 2.0.5 tem nada menos do que 170 MB :o), mas se você usa o Windows XP, pode baixar a versão 1.0.8, que oferece basicamente as mesmas funções e tem apenas 28 MB.
        Embora seja proprietário, o VMware Player é um aplicativo gratuito, você precisa apenas fazer um cadastro rápido para baixar. A instalação é feita na forma usual, no modelo "next > next > finish". Com o VMware instalado, o próximo passo é criar a máquina virtual. É aqui que entra a principal dica deste tópico, já que o VMware Player não permite criar as VMs, mas apenas executar máquinas virtuais previamente criadas.
        Ele é uma máquina virtual previamente configurada, pronta para usar, que funciona tanto em conjunto com o VMware Player for Windows, quanto na versão Linux. O arquivo compactado tem apenas 7 KB, pois um máquina virtual vazia é basicamente um conjunto de arquivos de configuração. O espaço usado cresce conforme você instala softwares dentro dela; logo depois de instalar o Ubuntu, por exemplo, a pasta estará com cerca de 2.8 GB.
        Comece descompactando a pasta em um diretório qualquer. Abra o VMware Player e indique o arquivo "linux.vmx", dentro da pasta. Inicialmente, a máquina virtual estará vazia, por isso o VMware ficará tentando dar boot via rede, depois de esgotar as outras possibilidades. Na verdade, esse é o comportamento esperado, que mostra que tudo está funcionando:
        O boot da VM é idêntico a um boot normal do PC, com a exceção de que tudo é feito dentro de uma janela. A máquina virtual é justamente um ambiente simulado, onde o sistema operacional guest (convidado) roda.
        Dentro da pasta, você encontra 4 arquivos. O "c.vmdk" é o disco virtual, que armazenará o sistema operacional e todos os programas instalados dentro da VM. Inicialmente ele é um arquivo vazio, mas ele vai crescendo conforme o uso. O seguinte é o arquivo "linux.nvram", que guarda as configurações do setup (sim, por estranho que possa parecer, a máquina virtual tem BIOS, e você acessa o setup pressionando a tecla F2 durante o boot).
        O "linux.vmx" é o arquivo de configuração da máquina virtual, um arquivo de texto, que você pode abrir (e até alterar) usando o notepad, e o "cd.iso" é outro arquivo vazio, que representa o CD-ROM virtual:
        Assim como em um PC de verdade, para usar a VM precisamos carregar algum sistema operacional. A primeira opção é simplesmente deixar um CD ou DVD gravado no drive. Ao abrir a VM, o VMware Player detecta a mídia e inicia o boot automaticamente. A segunda é usar um arquivo ISO em vez do CD gravado. Esta opção torna o boot bem mais rápido, pois o sistema é carregado a partir de um arquivo no HD, ao invés do CD-ROM. Nesse caso, substitua o arquivo "cd.iso" dentro da pasta com a máquina virtual pelo arquivo ISO da distribuição desejada, deletando o arquivo "cd.iso" original e renomeando o novo arquivo.
        O default das versões 2.x do VMware Player é sempre restaurar o status anterior da VM, o que vai lhe mandar de volta para a tela de boot via rede, onde ela estava antes de ser fechada. Use a opção "VMware Player > Troubleshoot > Reset" para realmente reiniciar a VM e dar boot através do CD. A partir daí, você dar boot e usar o sistema da forma normal:
        O padrão na maioria das distribuições é configurar o vídeo a 800x600 dentro do VMware, mas você pode alterar a resolução da forma normal, usando uma opção de boot ou o configurador dentro do sistema. No caso do Ubuntu, por exemplo, a opção está no "Sistema > Preferências > Resolução de Tela".
        Inicialmente, o VMware roda em uma janela, o que é uma forma prática de usar os dois sistemas simultaneamente. Você pode simplesmente configurar a VM para utilizar uma resolução de vídeo um pouco inferior à do seu monitor e usar o sistema como se fosse outro aplicativo qualquer. Outra opção é usar a VM em tela cheia, usando o botão de maximizar a janela. Nesse caso, você usa "Ctrl+Alt" para chavear entre os dois sistemas.
        Um inconveniente de usar o VMware Player em tela cheia é que você não tem como desabilitar o menu de funções que é exibido na parte superior da tela. Isso é um problema no caso do Ubuntu e outras distribuições com o GNOME, já que ela cobre a barra de tarefas, que é também exibida na parte superior. A solução é mover a barra para a parte inferior, clicando com o botão direto sobre uma área livre e acessando o "Propriedades":
        Outra configuração importante é a quantidade de memória RAM reservada para a máquina virtual. Por padrão, ela vem configurada para usar apenas 256 MB (o que é pouco para rodar a maioria das distribuições atuais), mas você pode alterar o valor clicando no "VMware Player > Troubleshot > Change Memory Allocation":
        O próprio VMware Player recomenda um valor, de acordo com o total de memória disponível, mas uma recomendação geral é que você reserve 256 MB em micros com 512 de memória ou de 384 a 512 MB (de acordo com a distribuição que pretender rodar dentro da VM) em micros com 1 GB:
        Tecnicamente, é possível usar o VMware Player mesmo em micros com apenas 256 MB de RAM, mas isso não é muito recomendável, pois com tão pouca memória, tudo ficará bastante lento.
        Continuando, existem duas formas de configurar a rede e acessar a internet de dentro da máquina virtual. A mais simples (e usada por padrão na VM pré-configurada) é o modo "NAT", onde o VMware Player cria uma rede virtual entre o sistema principal e a máquina virtual, permitindo que ela acesse a internet usando a conexão do sistema principal. Nesse modo, a máquina virtual recebe um endereço interno, atribuído automaticamente, como "192.168.150.129". Você só precisa deixar que o sistema configure a rede via DHCP. Além de acessar a web, o sistema dentro da VM pode acessar outras máquinas na rede local, mas não pode ser acessado diretamente por elas.
        A segunda opção é o modo "Bridged", onde a máquina virtual ganha acesso direto à rede local, exatamente como se fosse outro micro. Neste caso, você precisa configurar a rede manualmente (ou via DHCP), como se estivesse configurando um novo micro. Este modo é muito bom para estudar sobre redes, testar a configuração de servidores e assim por diante, pois você pode rodar várias VMs simultaneamente e simular uma rede completa, mesmo tendo apenas um micro.
        Para usar o modo Bridged, clique sobre a setinha ao lado do botão da placa de rede e mude a opção (é preciso reiniciar o VMware Player para que a mudança entre em vigor). Depois de reiniciar, não esqueça de reconfigurar a rede dentro da VM:
        Instalar o sistema dentro da VM não difere em nada de uma instalação normal. A VM pré-configurada usa um disco virtual de 20 GB, que você pode particionar a gosto, inclusive com a possibilidade de criar várias partições ou instalar dois ou mais sistemas em dual-boot.
        Naturalmente, ao "formatar" o HD virtual e instalar o sistema, nenhuma alteração é feita no seu HD. Tudo é feito dentro do arquivo "c.vmdk" na pasta da máquina virtual. O VMware faz com que o sistema rodando dentro da VM enxergue e particione este arquivo, achando que está manipulando um HD de 20 GB. Na verdade, é tudo simulado.
        Se quiser fazer um backup do sistema instalado ou copiá-lo para outra máquina, é só copiar a pasta (ela pode ser usada inclusive em máquinas rodando a versão Linux do VMware Player). Você pode também tirar cópias da pasta e assim criar várias VMs diferentes. Se o micro tiver memória RAM suficiente, é possível inclusive rodar várias VMs simultaneamente, simulando uma rede e trocando arquivos entre elas.
        O VMware permite também que dispositivos USB sejam usados dentro da máquina virtual, incluindo impressoras, scanners, smartphones, pendrives, etc.
        Ao plugar um pendrive, por exemplo, é criado um botão referente a ele na barra do VMware. Ao clicar no botão, o pendrive é conectado à máquina virtual, como se fosse um dispositivo local. Como você pode ver no screenshot, ele foi detectado pelo Ubuntu dentro da VM, que pode ler e salvar arquivos normalmente:
        O VMware Player inclui também um "setup", que você acessa pressionando "F2" logo depois de iniciar a máquina virtual. Através dele, você pode definir a ordem de boot (HD, CD-ROM ou rede), acertar a hora da máquina virtual, entre outras opções, assim como em um PC real.
        Você pode dar um toque final instalando o vmware-tools, um pacote de drivers que melhora o desempenho do sistema dentro da VM em diversas tarefas e adiciona um recurso de ajuste dinâmico do vídeo, onde a resolução do vídeo dentro da VM é ajustada automaticamente, permitindo que você redimensione a janela livremente, usando até mesmo formatos fora do convencional:
        Antes de instalá-lo, é necessário que você instale os headers do kernel e os compiladores básicos dentro da VM. O Ubuntu já vem com os headers e os compiladores podem ser instalados rapidamente usando o apt-get:
        $ sudo apt-get update
        $ sudo apt-get install build-essential
        Ainda a partir do terminal, acesse a pasta com os arquivos (se você baixou usando o Firefox, eles serão salvos por padrão dentro da pasta "Área de Trabalho" no diretório home) e descompacte o arquivo, como em:
        $ cd "Área de Trabalho"
        $ tar -zxvf vmware-tools.tar.gz
        Para instalar, acesse a pasta que será criada e rode o programa de instalação:
        $ cd vmware-tools-distrib/
        $ sudo ./vmware-install.pl
        O instalador faz várias perguntas, confirmando os diretórios de instalação dos componentes. Basta ir pressionando Enter para que ele instale tudo nos diretórios default. No final, ele confirma a resolução que será usada por default para o vídeo. Para que os drivers sejam carregados, é necessário reiniciar o ambiente gráfico (ou simplesmente reiniciar o sistema dentro da VM). Ele inclui também um configurador gráfico, que você pode abrir usando o comando "sudo vmware-toolbox".
        Em outras distribuições, os passos de instalação são os mesmos, com a diferença de que você executa os comandos diretamente como root, em vez de usar o sudo. O mais importante é ter instalados os headers e os compiladores, que são necessários para a instalação.
        Algumas distribuições, como o OpenSuSE, já trazem o vmware-tools pré-instalado, dispensando a instalação manual. No caso delas, basta instalar o sistema dentro da VM da forma normal.

Nenhum comentário:

Postar um comentário