Como já mencionei no prólogo do meu blog, já passei dos 30 anos, e acompanhei de perto o surgimento da nossa era digital. Parafraseando Carlos Cardoso, “meninos, eu vi”. Não é nada incomum encontrar amigos de gerações anteriores à minha reclamando da velocidade das coisas atualmente. Mesmo com meus mais de 20 anos em contato direto (pra não dizer profundo…. ui) com tecnologia da informação (não, não chamávamos assim “no meu tempo”), e com minha zona de conforto localizada na frente do computador, as vezes me flagro surpreso com a velocidade com a qual o conteúdo surge, se espalha e evapora na web.

Sempre fui mais adepto, por exemplo, dos meios de comunicação mais síncronos e bilaterais (pergunta -> resposta -> pergunta -> …) … BBS… IRC… ICQ… MSN… PQP! me perdi! Me perdi pois a velocidade de agora não permite mais o “síncrono”… não podemos mais nos limitar à velocidade do mais lento, e pra quem não encara nossa nova realidade de forma rasa, tem que correr pra acompanhar.

Agora sou “moderno”, falo em blog, no twitter, e já “me arrogo” a ponto de pensar em complementar com YouTube, afinal, haja ferramenta pra auxiliar a mim, o dinossauro digital criado na época da “escovação de bits” a não pensar mais em bits, e acompanhar a comunicação junto com a nova geração, dos TeraBytes.

A mídia impressa não acompanha mais… vimos ainda essa semana Obama encerrando a epopéia Osama, dando as caras no TrendingTopics do twitter, muitas horas antes de qualquer jornal sequer pensar em prensar. (Dica: Se você é editor de algum jornaléco, tá na hora de chamar o “garoto da informática” eventualmente à sua disposição e perguntar pra ele “o que é iPad e como se prensa conteúdo na tela dos distantes e misteriosos computadores”). E enquanto Twitter se revela a notícia mais rápida de todo oeste (e norte, e sul, e leste, e da put$ que par!$#*%), nosso conteúdo acelera. Enquanto escrevo esse post, provavelmente perdi 12841 notícias “importantes” na minha timeline, foram anunciadas a morte de três maritacas domesticadas, e 618416 emos fãs do Justin Bieber foram trollados no twitter. O encerramento da epopéia Osama já saiu dos TrendingTopics locais. Tempo… nunca foi tão escasso.

E a viagem no tempo tem efeitos colaterais? Claro! Pelo menos pra quem olha pela janelinha pra ver o mundo real. Pense bem na maneira como consumimos informação (literária, documentária, qualquer “ária” que você queira)… Pense bem na quantidade de chatos no twitter justificadamente retwittando algo com um #OLD na sua timeline (se você é um desses caras, saiba: é justificado mas ainda assim, É CHATO!). A sensação que mais me chama a atenção é justamente a mais óbvia: Já comprovamos que a proporção inversa que existe entre profundidade de abordagem e velocidade necessária para acompanhar o próximo assunto é inquebrável. A velocidade é cada vez mais alta… e a profundidade… bem… próximo assunto.

E essa é nossa era… A era do “próximo”. “Esse eu já li. Próximo. Pronto, esse também. Próximo”, e enquanto isso, no mundo real visto da janelinha, tudo fica cada vez menos próximo. É como se estivéssemos transformando livros em páginas. Isso é bom? É ruim? Prefiro pensar que é irrelevante enquanto causal, por ser um simples reflexo do nosso avanço, do nosso estilo de vida, e enquanto não tratarmos da origem dessa questão (nossa forma de experimentar o mundo, os filmes, os assuntos, as pessoas), tudo mais é irrelevante, mas não temos mais tempo pra isso, certo? Afinal de contas, nossa timeline está crescendo, e a cada tweet não visto, morre um hermitão surdo viciado em groselha nos arredores do Himalaia.

Grande abraço

E o #mimimi-sensação da vez (ele sempre volta em pauta) é a tal da proteção à nossa tão importante PRIVACIDADE, tão defendida pelos numerosos militantes pontuais do que chamo carinhosamente de “caUsa do caralh@”…

Tivemos essa semana revelações “bombásticas” (pffffff. HAHAHAHA… Tá bom) a respeito dos gadgets da Apple, que “obscuramente” estão registrando informações específicas a respeito da localização do seu usuário, sem que ninguém soubesse disso até então, ou pudesse optar pelo desligamento dessa “feature”. Os mais oportunistas de plantão já iniciaram seus processos contra Apple e Google por conta do tal “log de localização dos gadgets”. Mas vamos pensar com calma… E DAI???

Claro que pretendo chegar ao ponto principal, e falar do antagonismo presente na nossa presente luta em prol/repúdio (já não sei mais) da privacidade, mas vamos falar primeiro do menos importante… do que não escolhemos *diretamente*… do que é constante e portanto pode ser completamente eliminado da nossa equação pra que possamos tecer um julgamento CONSCIENTE sobre a questão. O que mais além dos gadgets da Apple ou da Google te monitora o tempo todo? Vamos enumerar:

1- Seu provedor de acesso a internet sem fio. Sim, se você utiliza uma conexão 3G, deve saber que apesar de seu provedor de acesso não ter sua localização com precisão de poucos metros de margem de erro, eles evidentemente são capazes de saber a quais torres de transmissão você está se conectando, e portanto enquanto você se locomove por ai feliz e contente com sua liberdade e conectividade móvel, SIM, você tem como ser “rastreado” e não há nada que você possa fazer quanto a isso;

2- Seu cartão de crédito… eu sei que você já assistiu filmes de ação, seriados de investigação policial, etc… e eles já devem ter feito você ter uma brilhante epifania que permitiu a você vislumbrar que a instituição financeira que provê seu cartão de crédito tem acesso a informações que permitem identificar onde e quando foi realizada sua última compra presencial com ele, bem como há um histórico disso, e não há nada que você possa fazer quanto a isso;

3- Seu provedor de acesso a internet (fixo), que você provavelmente usa na sua casa e/ou na sua empresa… não é só sua localização física “real” que pode ser rastreada, sua localização virtual também pode. Na maior parte dos países “civilizados” (LOL) do mundo, existem leis que obrigam os provedores de acesso a armazenarem por tempo prolongado, um histórico de tudo aquilo que você acessa a partir da sua conexão, que está em seu nome vinculada a sua pessoa física (RG e CPF) e/ou jurídica (CNPJ), ou seja, você também pode ser rastreado nas regiões que você frequenta no seu mundinho virtual (cofff… cofffff coffff…  porncofffff cofff…. que tosse!). Não se esqueça também que quase todo e qualquer webservice do mundo tem como logar seu IP, e até mesmo estimar (mesmo que sem precisão) sua geolocalização a partir dele em tempo real. Sempre que você conecta no seu GMail ou no seu Facebook, seu IP permanece lá, devidamente registrado, e com isso é possível estimar de que lugares físicos você realizou seus acessos.

4- Sistemas de rastreamento veicular… sério, não preciso explicar isso né?

Eu poderia prolongar essa lista citando outras tecnologias que talvez estejam presentes no seu cotidiano, como selos RFID dos “sem parar”-like services, que permitem que você não pegue filas em pedágios em estradas pelo mundo a fora, ou então poderia chegar ao extremo e falar de todas as câmeras de vigilância e segurança às quais você está exposto diariamente, mas não preciso me aprofundar esse aspecto do assunto.

Agora vamos ao aspecto realmente importante desse tema. Quem se importa realmente em proteger sua própria privacidade? Não me diga que você comprou seu tão sonhado iPhone 4, com GPS integrado, fotos com Geolocalização, cliente Twitter, cliente Facebook, FourSquare devidamente instalado, e escolheu justamente esse smartphone porque gostaria de permanecer na mais absoluta obscuridade. Fala sério. Não duvido nada que os espertalhões que estão processando Apple e Google tenham ferramentas como FourSquare instaladas no seu gadget, ou então que tenham o hábito de twittar aos quatro cantos da web (web tem cantos?) exatamente TUDO o que faz, onde, como e com quem.

A verdade é que nós estamos VOLUNTARIAMENTE transformando nosso cotidiano no romance de George Orwell, e agora todos ficam de MIMIMI porque nossos desejos foram atendidos. Todos queriam voz, todos queriam visibilidade, todos queriam publicidade, e agora se assustam com os efeitos colaterais ao invés de compreender nossa já consolidada decisão de fazer algo que pode se comparar a colar todos os nossos dados e informações pessoais diárias em postes públicos pelas ruas em todos os cantos do mundo. Usando uma metáfora pobre porém funcional, todo esse mimimi é como ver as pessoas “dando facadas no peito da privacidade” e gritando “digam pra ela parar de bater com o peito na minha faca!!!”.

São sejamos hipócritas ok? Nos condenamos a ser reféns de um “vórtice de entropia” composto por informações ultra-precisas a respeito de quase tudo em nossas vidas. Temos blogs, twitter, facebook, foursquare, e outros… Sim, se sistemas capazes de interpretação semântica puderem no futuro “organizar” nosso vórtice de entropia da informação, FO-DEU. Mas isso não fará com que você deixe de esperar ansiosamente seu iPhone 5, nem o 6, nem o 7, nem o 8 (que provavelmente medirá rua pressão arterial pelo toque na touch-screen, e proporcionará com acessórios homologados o tão sonhado exame de próstata de alguns), então, minha proposta:

Vamos fazer menos #mimimi a respeito dos efeitos colaterais do nosso ABANDONO CONSCIENTE E VOLUNTÁRIO da privacidade, e perder um pouco mais de tempo pensando numa maneira mais responsável e menos fútil/banal de utilizar as ferramentas que estão ao nosso dispor. Que tal?

Grande abraço a todos!

– Entendi!

– O que?

– TUDO.

– Como assim?

– Te digo.

Entendi qual o segredo da vida… o que se encaixa bem como propósito para ela.

O segredo da vida é a luta contra a luta. A competição contra a competição.

Se não entendeu, te explico.

Todos os nossos atuais problemas estão relacionados a uma única questão. A competição.

Por algum motivo, nosso sistema sócio-econômico impôs como um way of life, como uma necessidade, a competição. O sistema convenceu você de que a competição é necessária. Convenceu você de que você PRECISA VENCER.

– Vencer a quem?

– Qualquer um… TODOS. Te convenceram de que você precisa ser o melhor.

Só não sei por que, diabos, você acreditou nisso. Talvez porque seja a única referência que você recebeu do mundo.

Todos hoje querem se destacar

– Me destacar? Mas o “destaque” não está diretamente relacionado com “diferenças”? Com desigualdade? Com SEPARAÇÃO? Minha avó dizia que a União faz a força.

– Pois é. Ela estava certa, mas você não a ouviu, e pra você atualmente a União só faz açúcar.

Todos hoje querem ser donos da verdade, querem dinheiro. Querem controle. Querem o poder.

Vejo isso todos os dias da minha vida, ao meu redor, o tempo todo, até mesmo nesse escritório (não, não é a Matrix. Ou será que é? Bem, se é, sei que o Sistema não foi criado por uma horda de máquinas eletrônicas inteligentes, mas sim por uma horda de organismos biológicos burros).

Estou muito, muito cansado da competição… Evolucionistas contra criacionistas, religiosos contra ateus, software livre contra software proprietário, software livre contra SOFTWARE LIVRE, capitalismo contra capitalistas, Marxistas contra tudo e todos, Socialistas contra a realidade, esquerda contra direita, indústria contra evolução tecnológica, obsolescência contra qualidade, pobres contra ricos, ricos contra pobres, todo mundo contra todo mundo… eu contra mim mesmo.

Sou uma pessoa extremamente ansiosa. Como não ser? Enquanto todos estão preocupados em competir, eu me abraço ao fracasso… não como profissional, não como pai, não como marido, mas como SER HUMANO, responsável assim como você, por ação ou por omissão, por todo esse caos.

Por que diabos não podemos pegar todas essas forças opostas, e aproveitar o pouco que faz sentido em cada uma delas? Por que estamos tão presos ao método estúpido de defender alinhamentos filosóficos desconsiderando completamente a interseção que existe entre QUAISQUER conjuntos relacionados à cultura humana? Afinal, NO MÍNIMO, somos todos humanos, já temos pelo menos isso em comum. TODOS sofrem, também temos isso. NINGUÉM quer sofrer… toma mais esta.

Chegando aos finalmentes, insisto que conquistei meu próprio e talvez singular entendimento sobre o sentido da vida. Cheguei a um conceito que me satisfez quanto ao propósito dela… um propósito simples: a transferência de importância das responsabilidades individuais, para as coletivas, para que simplesmente possamos continuar existindo, evoluindo… coletivamente, ou seja, da única forma que permite a preservação de qualquer espécie.

E você acha que estamos preparados para nosso propósito? Bem, enquanto você se preocupa em competir ao invés de pensar nisso (afinal você é pé no chão, não é mesmo? Vive no mundo REAL, né? =) ), o otário sonhador aqui vai curtir mais um pouco do mau humor rabugento de alguém que percebe que a única luta necessária nessa vida, é contra a própria luta.

Descrevendo a água para quem está morrendo afogado, permaneço de mãos atadas sobre o Escudo de Aquiles, e espero pacientemente pela visita de mais algum conterrâneo do meu planeta que possa nos ajudar, ou pelo menos lamentar junto conosco, até que nosso falso propósito competitivo nos destrua.

Como eu já disse algumas vezes, coragem não se alimenta a distância, então não acredito que eu possa, ou sequer tenho a pretensão de estimular você a pensar sobre tudo isso com “apenas mais um” simples texto condenado ao fantástico poder da minha infâmia, afinal, todo o peso do mundo vai jogá-lo novamente à “realidade” em poucos minutos, não é mesmo? Mesmo assim, me resta ainda um pingo de esperança que alguém me prove que estou errado.

– Então quer dizer que eu não posso fazer nada a respeito?

Talvez possa. No mínimo, pensar a respeito não vai prejudicá-lo em nada.

Mantenho aqui no meu escritório um servidor Linux para diversas finalidades. Antes de mais nada, ele é meu gateway… ele fica entre meu roteador wireless e meu cable modem (ou seja, fica na borda da rede), e é ele quem fica responsável por entregar IPs para as máquinas da rede (DHCP server).

Além disso, uso nele um proxy transparente com cache HTTP (Squid 3) para economizar banda e acelerar a navegação para as máquinas da rede, e também um DNS server (Bind 9) para que eu me comunique com mais facilidade com minhas máquinas, dando nome na rede à cada uma delas, e também para que ele mantenha um cache DNS localmente, tornando mais rápida a resolução de nomes quando alguma máquina da rede vai acessar algum website ou serviço na web, que já foi acessado previamente, dispensando resolver nova e desnecessariamente um endereço web que já foi resolvido (mesmo a pedido de outra máquina da rede) e portanto já consta no cache DNS do servidor.

Além dessas funcionalidades básicas de rede, ele também se encarrega de alguns serviços que uso sempre, como servidor HTTP para testes que faço localmente, servidor de banco de dados MySQL, Firewall, etc… Mas dentre todas as funcionalidades que implementei nele, uma das mais importantes pra mim é o SSH.

Através do SSH (e também de fuse), eu costumo montar diretórios que costumo acessar muito no meu servidor local em outras máquinas da rede, para que eu possa acessá-los facilmente de qualquer máquina (em ambiente shell ou até mesmo no Finder), e também costumo montar diretórios do meu servidor web (onde o AptScience.org está hospedado) localmente, para que eu possa enviar, receber e trabalhar com arquivos remotos como se eles estivessem em um diretório local.

Além disso, costumo brincar bastante com meus amigos programadores, desenvolvendo código no meu servidor local, sendo que eles logam via SSH no meu servidor, e todos compartilhamos a mesma shell, escrevendo e lendo simultaneamente o mesmo código, através de multi-user screen ou tmux. Legal não?

SIM. Muito legal. Eu simplesmente não funcionaria sem SSH depois que me acostumei a fazer tanta coisa com ele. MAS, nem tudo são flores. Como mantenho um serviço passível de conexão remota rodando 24 horas por dia no meu servidor, a segurança é um dos fatores com os quais preciso me preocupar, para que minha máquina não seja invadida e controlada por quem eu não quero.

Não sou nenhum paranóico com segurança (cada um dos meus amigos que estiver lendo isso, deve estar rindo alto e dizendo “mentiroso do caralh@” ), e por isso, mantenho meu SSH rodando na porta padrão (porta 22), para que meus amigos não tenham o trabalho de especificar a porta na hora de conectar aqui, e também porque julgo desnecessário utilizá-lo numa porta diferente (até porque, grande parte das BotNets que ficam tentando invadir máquinas o tempo todo, fazem requests em portas aleatórias ou sequenciais, então, uma porta diferente não fará toda a diferença do mundo)… claro, desde que sejam tomados alguns cuidados de segurança que são justamente o foco desse artigo.

No Linux, os logs do SSH ficam normalmente mantidos no diretório /var/log, e são armazenados de forma rotativa nos arquivos auth.log* . Para que o administrador não tenha que lidar com um único arquivo de log gigantesco, os logs mais antigos vão sendo renomeados para auth.log.<número> e comprimidos com gzip, fazendo com que ocupem menos espaço em disco, porém ainda disponíveis para análise caso o administrador do servidor necessite.

Pra quem não sabe, uma BotNet, é uma rede constituída por programas que são executados de forma autônoma e automática. O termo bot vem evidentemente da palavra “robot” (robô), e enquanto o termo “BotNet” pode ser utilizado para descrever qualquer grupo de Bots (até mesmo os feitos com um propósito útil e funcional), ele normalmente é utilizado como referência a um grupo de máquinas zumbis, ou seja, máquinas que foram infectadas por worms, cavalos de Tróia, ou outros programas maliciosos, e agora estão subjulgadas a estes programas, executando tarefas sem que seus usuários sequer percebam. Se você já foi contaminado por algum trojan, provavelmente sua máquina já fez parte de uma BotNet. E talvez ela já tenha até mesmo tentado invadir meu servidor! Mundo pequeno, não?

Pois bem… como um dos meus mais importantes hobbys é estudar TI, e investigar o funcionamento das coisas, decidi compartilhar uma de minhas brincadeiras com vocês. Ela consiste em um simples shell script, que pega todos os logs relacionados a autenticação de usuários no meu servidor, junta todos em um arquivo, e aplica alguns filtros (todos realizados através do meu próprio script, usando ferramentas convencionais de sistemas Unix based) para gerar pra mim algumas estatísticas que julgo interessantes. No caso do script em questão, eu planejei gerar estatísticas sobre os nomes de usuários que as BotNets mais tentam na hora de invadir máquinas aleatoriamente ou sequencialmente via internet.

Vejam aqui o código do script que fiz para nossa brincadeira:  < log_botnets.sh >

Como até agora (por enquanto) já fiz dois artigos sobre ambiente shell, aproveite o script (que é simples, e que também não me dei ao trabalho de “enxugar” ou aperfeiçoar, para estudar shell script caso queira).

Meu simples script, me retornou o que planejei para satisfazer minha curiosidade sobre os nomes que as botnets mais tentam utilizar na hora de tentar invadir máquinas via SSH. E pra que? Simples, para que eu saiba os nomes de usuário mais perigosos pra se utilizar em uma máquina. Se você utiliza um nome de usuário ordinário e previsível, e tem uma senha fraca, você aumenta MUITO as chances de uma botnet invadir sua máquina via SSH. Então evite usar os nomes mais comuns.

Segue o conteúdo do arquivo gerado pelo meu script, que revela os nomes mais utilizados. No formato que planejei para o conteúdo do arquivo, constam o número de vezes que um nome de usuário já foi utilizado em uma tentativa de invasão ao meu servidor, seguido do respectivo nome de usuário que foi utilizado pela botnet nessa tentativa. Como reconfigurei meu servidor há apenas duas semanas, esses dados são referentes apenas a este intervalo, ou seja, se referem às tentativas de invasão ao meu servidor nas últimas duas semanas.

Resultado do script: < ssh_usertries.log >

Interessante, não?

No próximo artigo, vou falar um pouco sobre senhas, e segurança de usuário.

Grande abraço a todos.

Como você provavelmente já sabe, o Mac OS X funciona sobre um Kernel BSD (Darwin BSD), e por isso você já encontra por padrão, como em praticamente todos os sistemas operacionais Unix Based, com muitas das ferramentas de linha de comando que estamos acostumados a utilizar em sistemas Linux, disponíveis assim que você abre um terminal.

Para não perder muito tempo com explicações desnecessárias, vou direto aos aspectos práticos dentre aqueles que notei como “comuns” à fase inicial de migração de qualquer usuário Linux para a plataforma Mac (afinal de contas, se você está lendo informações referentes a terminal e linha de comando, provavelmente já possui um conhecimento razoável).

Se você está migrando direto para a versão mais nova do Mac OS X (Snow Leopard), vai notar provavelmente com grande alegria que a Apple, assim como a maioria dos sistemas operacionais Unix based, definiu o Bash como a shell padrão, a despeito do que ocorria em versões mais antigas (se não me engano no Panther – versão 10.3 do Mac OS X – ainda utilizavam tcsh como shell padrão. Pra quem não conhece a história, tivemos os felinos Cheetah, Puma, Jaguar, Panther, Tiger, Leopard e Snow Leopard, nessa respectiva ordem, como versões do Mac OS X ) …

Pois bem… Se você, como a maioria dos usuários Linux já está acostumado com bash, ótimo (caso não tenha muita familiaridade com ambiente shell, recomendo que leia meu artigo “Quem tem medo do terminal? lá lá lá“, e caso possua dúvidas, não tenha vergonha de entrar em contato e perguntar). Particularmente, sempre gostei de usar Bash (apesar de o tab/auto-completion ser inferior ao de algumas outras shells), e por isso me sinto bastante confortável utilizando ele no Mac OS X. Evidentemente você pode utilizar o mesmo padrão que existia no Panther ( tcsh ) e anteriores como shell padrão caso queira, ou qualquer outro ambiente shell.

Bem, conhecido o interpretador padrão, hora de começar a trabalhar. Quando comecei a usar ambiente shell no Mac OS X, testei alguns dos meus scripts e configurações que sempre utilizei no Linux, e quase tudo ocorreu bem, exceto por alguns probleminhas e incompatibilidades que tive que resolver / adaptar, e um dos primeiros probleminhas que percebi foi: o editor de textos que costumo usar ( vim ), que já está presente por padrão no Snow Leopard, estava com meu esquema pessoal de cores (syntax highlightning) completamente bagunçado, mesmo apesar de minha configuração habitual estar correta… ou seja… o Terminal.app não estava me oferecendo nativamente e por padrão, 256 cores na shell.

Apesar de as features oferecidas pelo Terminal.app serem relativamente satisfatórias pra quem raramente usa ambiente shell, eu sempre quis soluções de terminais mais completas, então eu CERTAMENTE não aceitaria trabalhar em ambiente shell no Mac OS X perdendo meu prévio acesso a 256 cores, do qual eu já desfrutava no Linux. Então passei a pesquisar pelas melhores opções de terminais disponíveis. Foi então que eu conheci, e acabei me casando com o iTerm, por ser pra mim uma opção perfeita, que é flexível o bastante pra não me desapontar em termos de consumo de recursos, agilidade, features, e até mesmo aparência.

O iTerm, é um terminal bem completinho, com algumas features bem interessantes. Vou citar apenas algumas:

• Modo FullScreen para um ambiente de trabalho livre de distrações;
• Possibilidade de firulas visuais, como janela de fundo transparente (com blur! isso é bacana, pra não gerar confusão visual) ou imagens de fundo;
• Suporte nativo a 256 cores;
• Suporte a “select to copy”, e paste com clique de botão do meio do mouse;
• Suporte a AppleScript e Bonjour;
• Suporte a Tabs (abas) com alertas de atividade;
• Suporte a bookmarks e profiles, para que você possa customizar “sessões”.

Se você nunca experimentou o iTerm, recomendo que instale e teste.

Link para o site do projeto: < iTerm >

Bem, com meu terminal instalado e devidamente customizado (creio que você não vai ter dificuldade com isso, pois a configuração dele é bem straightforward, mas se tiver alguma dúvida não deixe de me perguntar, ajudo com prazer), faltava apenas ajustar algumas configurações do ambiente shell que costumo utilizar… meu .bashrc e .bash_profile, as configurações do meu vim, as configurações do tmux, o git, e outras coisas importantes pra quem usa bastante ambiente shell, principalmente pra desenvolvimento.

Vou falar de cada um desses detalhes nos próximos posts, abordando cada um separadamente, já que o assunto pode se extender bastante, e que são de fundamental importância, pois são justamente as configurações que me permitem um ambiente de trabalho dinâmico e prático em modo texto no meu Mac OS X.

Mas desde já, vamos falar de outro quesito importante da migração dos pinguins: “e quanto aos aplicativos Linux que não estão disponíveis por padrão no Mac OS X?”

Bem para isso existem várias soluções, e a que mais me agradou até hoje foi o Homebrew.

O Homebrew é uma espécie de “gerenciador de pacotes” para o Mac OS X, que de forma automática e simples, baixa aplicativos em código fonte, os compila e os instala pra você, a partir de “formulas”, que são instruções prontas que dizem a ele qual a forma correta de fazer isso para cada caso / aplicativo. Ele é feito em Ruby, e tem algumas características muito importantes que o diferem das demais soluções existentes para esta finalidade no Mac OS.

A primeira e mais importante delas na minha modesta opinião, é que ele não bagunça seu sistema. Quando você instala um aplicativo (pacote) com o Homebrew, este aplicativo é instalado no seu próprio diretório “isolado” ( /usr/local/Cellar/<pacote_instalado> ). O Homebrew então apenas cria links simbólicos, em /usr/local,  para os binários executáveis dos aplicativos que ele instala pra você. Dessa forma, cada programa instalado fica bem organizado e isolado dos demais. Como o diretório /usr/local está na variável $PATH do ambiente shell, você pode executar os binários de qualquer programa que instalou através do Homebrew a partir de qualquer outro diretório. Com esse método de organização, é muito simples, fácil e LIMPO, instalar ou remover qualquer coisa com o Homebrew, mesmo que você queira, de uma só vez, remover TUDO o que já instalou com o Homebrew.

A segunda, é que o Homebrew depois de instalado não exige que você execute NENHUM comando com permissões de superusuário/root para instalar ou remover algum programa, já que ele apenas trabalha em diretórios que tem permissão de leitura E escrita para o usuário “comum” do sistema. Ou seja, você tem bastante segurança, uma vez que para utilizá-lo você não vai executar nenhum comando como root, ficando assim absolutamente preservada a integridade de arquivos e diretórios fundamentais do sistema. Isso faz com que seja praticamente impossível que um comando errado no Homebrew “cague com coisas importantes” .

A terceira, é que ele não instala nenhuma dependência duplicada, ou seja, se um programa instalado pelo Homebrew precisa de alguma dependência com a qual o seu Mac OS X já conta nativamente (já a tem instalada por padrão), ele não instala essa dependência redundante no seu sistema, e usa a versão que é oferecida nativamente pelo Mac OS.

O Homebrew foi desenvolvido com base em Ruby, e todos os seus pacotes são baixados, compilados e instalados com base nas “formulas“, que são na verdade scripts super simples em Ruby que informam a ao Homebrew como deve ser compilado e instalado cada aplicativo. Dessa mesma forma, você  pode criar suas próprias fórmulas para criar um novo “pacote” que o Homebrew ainda não ofereça, ou até mesmo adaptar formulas já existentes de acordo com as suas necessidades… de qualquer forma, duvido que você vá desfrutar dessa possibilidade, já que o número de aplicativos disponíveis no Homebrew já é bem grande e estes estão constantemente atualizados e otimizados. Além disso, a base de pacotes disponíveis no Homebrew cresce mais a cada dia, assim como a sua adoção dentre os usuários do Mac OS X que costumam utilizar ferramentas do Linux.

Então vamos à parte prática… Instalá-lo em seu sistema.

Antes de mais nada, instale o Xcode (ambiente de desenvolvimento do Mac OS X que vai lhe oferecer, além de muitas ferramentas próprias para o desenvolvimento para Mac e/ou iPhone e iPad, as ferramentas de compilação básicas de sistemas Unix Based que você precisa que estejam instaladas para que o Homebrew possa compilar automaticamente os aplicativos que você instala através dele.). Você pode instalar o Xcode a partir do próprio CD do Snow Leopard (ele está lá, disponível para que você o instale, basta que você procure na parte de instalações extras), ou então do próprio website do Apple Developer. (caso tenha alguma dúvida, INSISTO, não tenha vergonha de me procurar pra perguntar)

Em segundo lugar, instale o git (acredite, você ainda vai precisar disso se pretende utilizar ambiente shell, principalmente se for utilizar para desenvolvimento). Você pode instalar o git de diversas formas, inclusive através de SVN (já que o Mac OS X já tem SVN instalado por padrão), ou até mesmo através do próprio Homebrew, mas eu particularmente prefiro ter o git instalado de forma independente. Então, caso queira seguir meu exemplo, da forma mais simples possível, você pode simplesmente instalar o binário pré-compilado da versão estável mais recente. Basta baixar, clicar, e pronto, instalado. (clique <aqui> se você é preguiçoso o bastante, a ponto de não querer procurar o binário de instalação por sua conta )

Pronto…

Feito isso agora é só você instalar o Homebrew através da simples linha de comando:

ruby -e "$(curl -fsS http://gist.github.com/raw/323731/install_homebrew.rb)"


Apenas para a instalação do Homebrew, este comando deve ser executado com permissões de administrador (root), então, não se esqueça de usar sudo junto com o comando ( sudo <comando> ). Este artigo evidentemente é pontual e datado, portanto esse comando de instalação pode mudar com o tempo, então no caso de qualquer erro ou dúvida, visite a página de instruções de instalação do Homebrew no próprio site do projeto. O que posso garantir é que vai ser sempre tão simples como o comando acima .

Agora, com ele já instalado, você já está pronto para instalar aplicativos Linux no seu Mac OS X.

Para atualizar as fórmulas disponíveis no seu Homebrew, use o comando:

brew update


Quando quiser instalar algum aplicativo, use o comando:

brew install <nome_do_aplicativo>


Se você quiser instalar, por exemplo, o wget, use o comando:

brew install wget


Para ver todas as fórmulas disponíveis, use o comando:

brew search


Simples não? Não deixem de visitar a < Wiki do projeto > para maiores esclarecimentos.

Se tiverem dúvidas gritem, e por hoje é só pessoal.

Grande abraço.

Hoje -> Estive lendo os artigos mais antigos que escrevi, quando encontrei esse texto, que alias foi um dos que me proporcionou mais satisfação ao escrever. Em primeiro lugar porque ele trata do surgimento do Unix, sistema operacional/assunto que sempre me despertou uma paixão enorme. Em segundo lugar, por tratar da história dos sistemas computacionais. Eu nasci em 1979, e meu primeiro computador foi um Apple TK3000 IIe (eu tinha aproximadamente 12 anos), com seus fantásticos 256KB de memória RAM. HD na época era algo inimaginável para reles mortais… apenas grandes empresas podiam desfrutar de tamanho luxo, e as que desfrutavam, dispunham por volta de 20MB de espaço de armazenamento em seus HDs (espaço que atualmente é risível, mesmo para pendrives).

Quando eu comecei a usar meu TK3000, não tinha nem mouse… na época, usávamos drives de disquete de 5.25″ que chamávamos carinhosamente de Horácio (o bicho trabalhando dava até medo em consequencia dos ruídos que emitia) que nos permitiam gravar disquetes flexíveis de 360KB, e que nos obrigava a virar o disco na metade da gravação, e um gravadorzinho de fita K7, que me proporcionou minhas primeiras gravações de experiências feitas com minha “superpotente máquina” da época . Depois de alguns anos, tive meu primeiro PC XT, depois meu primeiro PC AT, meu primeiro 386. Até chegar na era 486, eu já tinha passado por alguns sistemas operacionais, e aprendido a programar em BASIC, passado por inúmeras BBSs, em fim, com tudo que um nerd nos anos 80 tinha direito… Justamente por acompanhar alguns momentos históricos (como por exemplo o surgimento da Internet), acho muito interessante estudar tudo o que rolou antes da minha chegada ao mundo da tecnologia.

Quando publiquei este artigo pela primeira vez (muito… muito tempo atrás), meu blog ainda não estava em nenhum planeta, e nem mesmo no Google, e por isso este artigo especificamente não recebeu absolutamente nenhuma visita. Decidi então republicá-lo hoje, pra contar um pouco da história do GNU/Linux e seus ancestrais (para familiarizar non-geeks com a história do sistema, já que obviamente a grande maioria dos geeks já conhece todos os “causos da carochinha” relacionados ao nosso SO). Beleza… Mãos à obra… Vamos voltar um pouco no tempo. Mais precisamente, vamos voltar exatamente 148 anos no tempo e começar nosso conto por “lá”.

1861 -> William Barton Rogers funda o MIT (Massachusetts Institute of Technology)…

“Ta bom, mas o que que eu tenho com isso?” Calma, você vai entender por que eu citei. Pra quem não sabe, o MIT é um dos mais renomados estabelecimentos de ensino superior do mundo, oferecendo hoje mais de 900 cursos nas áreas de ciência e tecnologia.

Depois de 4 anos de “água-de-salsicha” em virtude da Guerra Civil Americana, o MIT iniciou a admissão de seus primeiros alunos em 1865… Vamos pular 96 anos de evolução para que você entenda o por que da citação do MIT…

1961 -> Primeira demonstração do CTSS…

O CTSS (Compatible Time-Sharing System), desenvolvido no Centro de Computação do MIT e demonstrado pela primeira vez rodando em um IBM 709 e portado 1 ano depois para um novo hardware (IBM 7090), foi um dos primeiros sistemas operacionais a adotar a técnica de time-sharing empregada até hoje permitindo que vários usuários possam utilizar um ambiente pra executar programas sobre o mesmo sistema operacional rodando em uma máquina (moderno não? ). Esse tipo de sistema é caracterizado pelo  compartilhamento de processador, memória e disco, entre vários usuários.

1962 -> O projeto MAC…

Em novembro de 1962, um integrante do MIT chamado Joseph Carl Roubnett Licklider propôs o projeto MAC (Multiple Access Computers ou Man And Computers, devido a dualidade de objetivos do projeto), criado para desenvolver um sistema operacional avançado e um laboratório de inteligência artificial. Um ano depois, realizou-se um estudo reunindo vários cientistas da computação em Cambridge com o objetivo de divulgar o CTSS e discutir o futuro da computação. Este estudo resultou em um importantíssimo subprojeto… o Multics (MULTiplexed Information and Computing Service)…

1963 -> O início do sistema operacional Multics…

Ainda em 1963, o projeto MAC começou a tomar grandes proporções e ganhou o apoio da ARPA (Advanced Research Projects Agency, subordinada ao Departamento de Defesa dos EUA), da Bell Labs, GE (General Eletric) e da IBM (que após a divulgação das especificações de hardware para rodar o Multics, ofereceu o IBM 360, lançado naquele ano, para abrigar o sistema).

O objetivo do projeto Multics era um sistema operacional com suporte para memória virtual, utilizando recursos de paginação e segmentação de memória, possibilitando um processo mais sofisticado de transferência de dados entre discos de memória.

Em 1964, a GE propôs a utilização do Multics em um mainframe GE-645, que também foi comprado pela Bell Labs no início de 1965, quando a mesma juntou-se definitivamente à equipe de desenvolvimento do Multics, apresentando a primeira descrição definitiva do sistema numa sessão especial na Fall Joint Computer Conference, ocasião em que muitos tomaram por impossível a ambiciosa tarefa da equipe de desenvolvimento do projeto devido aos recursos da época. A partir dai, foi finalmente escolhida a linguagem PL/I para gerar o código do Multics, iniciando-se assim efetivamente o desenvolvimento do sistema operacional, usando o CTSS como sistema para o trabalho dos desenvolvedores. Com o passar do tempo (MUITO tempo), o próprio Multics passou a ser utilizado para o seu desenvolvimento, porém, sem resultados rápidos, o que gerava uma grande frustração da equipe de desenvolvimento, frustração que acabou levando a Bell Labs, em abril de 1969, a retirar-se do projeto. Apesar disso, o Multics foi, ainda em 1969, disponibilizado para comercialização e utilizado por várias organizações importantes, tais como a Força Aérea Americana, a General Motors e a Ford.

O desenvolvimento do Multics foi cancelado em 1985, tendo depois disso sua utilização suspensa por várias organizações (diz a lenda que o último Multics sobrevivente em produção foi desativado no ano 2000 no Quartel General do Comando Marítimo Canadense).

1969 -> Surge o embrião do projeto UNIX…

Motivados pelo projeto Multics, Ken Thompson e Dennis Ritchie (que até então eram integrantes do projeto Multics, e que mantiveram contato pessoal com profissionais do Bell Labs mesmo depois que a Bell abandonou o projeto) deram início ao desenvolvimento de um projeto pessoal chamado Unics (UNiplexed Information and Computing Service).

O projeto Unics, tinha como objetivo fazer (COM RAPIDEZ) um sistema operacional simples, versátil e moderno, mantendo todas as idéias de time-sharing e implementando portabilidade como um dos objetivos do novo sistema. O nome Unics surgiu como um trocadilho referente à modéstia do novo sistema com relação as grandiosas metas do projeto Multics (Em 1970 o nome foi mudado para Unix com uma sugestão de Brian Kernighan, funcionário do Bell Labs, integrante do novo projeto).

Depois de duas solicitações de investimento para o projeto pleiteadas junto ao Bell Labs (visando adquirir um computador de médio porte para o sistema) seren recusadas, e de uma grande falta de incentivo, Thompson, Ritchie e Rudd Canaday (outro integrante do Bell Labs que participou do projeto), começaram a desenvolver todo o projeto “no papel”, e traçaram toda a teoria sobre o filesystem (necessário para uma utilização correta dos discos por parte do sistema operacional) e sobre o Kernel (o núcleo do sistema operacional, que faz toda a intermediação entre o hardware e os processos em execução). Thompson encontrou então um computador (DEC PDP-7) relativamente velho e abandonado em outro departamento do Bell Labs e finalmente conseguiu sua transferência para o projeto.

Ainda em 1969, Thompson começou a implementar o projeto do filesystem (chamado sarcasticamente de “chalk filesystem” por Ritchie, devido ao seu projeto ter sido realizado (forçadamente) em um quadro negro com giz), e também dividiu o projeto em quatro blocos com o objetivo de organizar o cronograma do projeto em 1 mês:  1) Sistema Operacional, 2) Shell (ambiente próprio para entrada de linhas de comandos), 3) Editor de texto, e 4) Compilação do sistema e dos programas.

O PDP-7 foi substituído em 1970 por um DEC PDP-11, já que o 7 estava se tornando rapidamente obsoleto e o Bell Labs percebeu finalmente opotencial e a rápida evolução do projeto, e assim decidiu começar a investir mais.

A primeira versão do Unix foi escrita em Assembly que por ser uma linguagem relativamente complicada, tinha que ser substituída por uma linguagem de nível mais alto… Fortran foi descartada logo de cara… Foi decidido então o uso da BCPL (Basic Combined Programming Language), conhecida como B (obviamente pois é a primeira letra do nome)… OPA! Problemas: Lentidão (já que a linguagem tinha que ser interpretada) e Incompatibilidade (pois o PDP-7 tinha um processamento word-oriented – orientado em palavras – , e o PDP-11 tinha processamento byte-oriented – ou orientado em bytes)… Mas tranquilo… Para o Richie não tinha tempo ruim… Ele usou o PDP-11 para adicionar funcionalidades ao B, que passou a se chamar NB (new B), e em seguida, providenciou um compilador para o NB pra resolver o problema da lentidão gerada pela interpretação… Tchanaaaaaaam !!! Nasce então a interplanetariamente famosa Linguagem C (nome que surgiu da utilização da segunda letra do BCPL).

Em 1973, foi implementado por Thompson o conceito de pipe (criado por Douglas McIlroy) que permitia que vários processos fossem “amarrados” gerando uma única saída ou resultado final.

1976 -> O Unix vai pras universidades

En 1976, Thompson foi dar aula na Universidade de Berkeley na Califórnia. O Unix então se espalhou rapidamente por inúmeras universidades. Quando Thompson voltou para o Bell Labs, o Unix continuou a ser desenvolvido por professores e universitários (tendo em vista que seu código era aberto e possuía uma licença universitária) e foi assim criado o BSD (Berkeley Software Distribution), uma versão do Unix inicialmente adaptada ao ambiente universitário. Os BSD atualmente são muito utilizados, sendo os derivados mais conhecidos: FreeBSD, NetBSD, OpenBSD, e também devemos citar o MacOS, que é baseado no Darwin. Algumas empresas também desenvolveram seus próprios sistemas baseados em Unix, tais como o Solaris e SunOS (Sun Microsystems), HP-UX (Helwett-Packard), Tru64 Unix (Compaq), OpenServer (SCO), AIX (IBM), Xenix (SCO, AT&T e Microsoft), etc…

Bom, agora chegou a hora de falar um pouco sobre o RMS… Richard Matthew Stallman mas não vou me aprofundar muito (pelo menos não nesse tópico) porque afinal de contas o figura merece um tópico só dele, por ser uma figura polêmica, radical (além do tolerável IMHO). BTW, recomendo a todos (que lêem com facilidade documentos em inglês) a leitura do openbook Free as in Freedom: Richard Stallman Crusade for Free Software da O’Reilly Media, escrito por Sam Williams em 2002 (Quando tiverem tempo, cliquem e leiam).

Vamos então falar diretamente e objetivamente do do projeto GNU e do surgimento do Kernel Linux…

1984 -> Início do projeto GNU…

Em 1984 Richard Stallman fundou o projeto GNU com o objetivo de criar um sistema operacional TOTALMENTE livre (o nome GNU além de sua proveniência óbvia do mamífero ruminante, vem do trocadilho acrônimo “GNU’s Not Unix”, já que o GNU tem uma concepção REALMENTE livre, ao contrário do Unix, que era livre e deixou de ser). O projeto refere-se a uma série de aplicativos totalmente livres que Stallman e vários outros programadores que abraçaram a causa desenvolveram como peças principais de um sistema operacional completo e livre…

1991 -> O momento determinante da nossa história…

Em 1991 o sistema de Stallman e seus colegas já estava quase pronto, mas faltava apenas um pequeno detalhe (rsrsrsrs)… O cérebro… O Kernel do sistema operacional. A equipe de desenvolvimento do GNU estava desenvolvendo um Kernel chamado Hurd, composto por daemons que utilizam o microkernel GNU Mach. Eis que então, exatamente em 05 de outubro de 1991, um jovem finlandês estudante da universidade de Helsinque chamado Linus Benedict Torvalds, provavelmente sem a menor idéia da magnitude de sua recente criação, postou uma mensagem (a fomosa) no newsgroup comp.os.minix anunciando que havia criado um kernel funcional (versão 0.02) que já rodava bash, gcc, gnu-make, gnu-seed, compress, etc… Na mesma mensagem ele disse que as fontes de seu novo Kernel estavam disponíveis para ampla divulgação, e que estava interessado em entrar em contato com pessoas que tivessem escrito utilitários/bibliotecas para o Minix com códigos livremente distribuídos (sob licença ou domínio público) para que pudesse adicionar de forma autorizada ao sistema.

Esta mensagem foi a mensagem oficial de lançamento do Kernel Linux, e por isso o aniversário do SO Linux é comemorado em 05 de outubro, dia da postagem da mensagem no newsgroup anunciando sua criação. Desde o início, Linus distribuiu seu Kernel exclusivamente com programas criados pela Free Software Foundation para o Projeto GNU, pois se todos os programas da FSF funcionassem bem com o Kernel Linux, seria uma prova de que o kernel estava devidamente ajustado ao kernel Unix…

Pronto… Chegamos finalmente ao surgimento do nosso sistema operacional GNU com Kernel Linux chamado GNU/Linux !!!

Normalmente por desconhecimento ou por questão de comodidade as pessoas utilizam simplesmente o nome Linux (nome do Kernel ou núcleo desenvolvido por Linus Torvalds) para falar do sistema operacional…

O GNU/Linux até o lançamento de sua versão 2.6 (que ocorreu em dezembro de 2003) tinha suas versões classificadas como versões em desenvolvimento ou versões estáveis de acordo com o segundo número. Ou seja, se falássemos do kernel 2.5.8 (segundo número ímpar) estaríamos tratando de uma versão em desenvolvimento. Já com o segundo número par, estaríamos tratando de uma versão estável. A partir do kernel 2.6, o kernel em desenvolvimento passou a ser identificável pela ausência do quarto número (que representa versão final considerada estavel).

Hoje em dia temos disponíveis para utilização inúmeras distribuições do GNU/Linux, que reúnem diversos aplicativos (sejam eles da Free Software Foundation ou não). Falando de maneira simplificada, uma distribuição nada mais é do que o Kernel Linux combinado com programas compatíveis com ele.

Bom, chega por hoje… Comentários, correções e acréscimos são extremamente bem vindos.

Grande abraço a todos!

Telinha preta, janelinha de texto, terminal, console, e muitos outros, são os termos que mais costumo ouvir de usuários que não tem muita familiaridade com esse recurso. Ouço muito “bah… não saberia usar o Linux… não sei usar aquela janelinha de texto…”. Atualmente temos muitas distribuições Linux em que o usuário pode fazer tudo através da interface gráfica, sem a menor necessidade de utilizar o terminal. Porém, muitos de nós que usamos o Linux há muito tempo, já nos acostumamos a realizar tarefas de maneira mais rápida pelo terminal. E as vezes realmente o domínio dessa interface pode realmente tornar mais fácil, flexível e direta a administração do sistema.

Pois bem… Minha intenção com esse post é desmistificar um pouco os terminais para aqueles que ainda não conhecem bem seus recursos, e passar algumas dicas, comandos e short-cuts legais, até mesmo para aqueles que já o conhecem porém não utilizam. Não pretendo de forma alguma me aprofundar tecnicamente no assunto, pois o mesmo é MUITO vasto, e mesmo com ANOS de estudo sobre ele, sempre se aprende alguma coisa nova… resumindo, é digno de um blog exclusivo para o assunto. Por isso, apenas quero abordar o assunto de forma a incentivar o estudo do usuário por sí só, e a pesquisa em prol do domínio da ferramenta. Vamos ao que interessa…

Shell (ou terminal), é simplesmente uma interface de comando. É um interpretador que atua entre o usuário e o complexo “cérebro eletrônico” à sua frente, traduzindo seus comandos e expressões de forma que o sistema possa entender qual a tarefa desejada e então executá-la. Simples não? Podemos dizer de forma mais superficial e genérica que os terminais são interpretadores de comandos. Quando utilizamos a interface gráfica para manipular arquivos, por exemplo, temos o ambiente gráfico em questão passando todas as instruções para o sistema do que deve ser feito… mas muitas vezes, as tarefas mais comuns previstas pelo desenvolvedor do ambiente gráfico não são o bastante, e queremos realizar de uma só vez, ações ou combinações mais complexas de tarefas, e é nessa hora que o terminal se torna necessário. Você pode utilizar sua interface gráfica para pegar todos os arquivos de um diretório e mover para outro diretório… mas, por exemplo, quando o que você quer é pegar todos os arquivos de um diretório cujos nomes comecem com a letra E, DESDE QUE não existam num segundo diretório especificado, e copiá-los para uma outro diretório comprimindo automáticamente cada um para dentro de arquivos .tar.bz2… Ai a tarefa se torna mais complicada não é mesmo? E não podemos fazer de maneira automatizada com a interface gráfica… não ao menos numa tacada só. Mas utilizando alguns recursos da shell combinados numa única linha de comando, ou então num bash script, você pode. Além disso, a shell é extremamente necessária em sistemas dedicados, em que uma interface gráfica consumiria recursos da máquina sem necessidade. Se você possui uma máquina que vai simplesmente atuar como um servidor dedicado para alguma função específica, provavelmente é mais interessante permitir que TODOS os recursos da máquina estejam disponíveis para o serviço desejado, sem consumir processamento ou memória com inferfaces gráficas.

Existem diversos interpretadores de comando disponíveis em sistemas Linux ou quaisquer outros sistemas Unix-based, dentre os quais podemos destacar os seguintes:

• sh – ou Bourne Shell foi desenvolvido por Stephen Bourne dos laboratórios AT&T em 1977 para substituir o Thompson Shell no sistema Unix versão 7. Por ser um shell robusto, e também por ser distribuido com o Unix 7 que era muito popular em Universidades, o Bourne shell logo se tornou um shell muito popular para contas Unix. Ainda permanece como o shell padrão para o superusuário (root) em muitas distribuições de sistemas Unix-like;
• bash – ou GNU Bourne-Again Shell é um interpretador multiplataforma (POSIX) desenvolvido por Chet Ramey para o Projeto GNU da Free Software Foundation, que se tornou padrão em várias distribuições Linux, podendo ser usado também em qualquer outro sistema operacional Unix-like compatível com a família de normas POSIX. O bash é compatível com o Bourne Shell e incorpora os melhores recursos do csh e do ksh (descritos abaixo);
• csh – ou C Shell, desenvolvido por Bill Joy da universidade de Berkeley e derivado da sexta geração do Thompson Shell (antecessor do Bourne shell), teve sua sintaxe modelada segundo a linguagem de programação C, e adicionou ao sh recursos como aliases e histórico de comandos. Atualmente está em desuso por ter sido superado por outros shells mais evoluidos que também implementam tais recursos;
• tcsh – ou Tenex C shell, foi um shell baseado originalmente no csh, que adicionou ao mesmo complementação de nome de arquivos e edição de linhas de comando (funcionalidades presentes no ksh (descrito abaixo) e parcialmente no bash);
• ksh – ou Korn Shell, desenvolvido por David Korn do Bell Labs, é um shell com retroativamente compatível com o Bourne Shell que além de possuir todas as funcionalidades do sh e agrega também muitas outras funcionalidades do C shell (tais como histórico de comandos, Arrays associativas e aritmética nativa de ponto flutiante), que permitem que o mesmo seja utilizado como uma linguagem de programação.

Nos sistemas Linux, e em muitos outros que também são “Unix-like” (similares ao Unix) ou “Unix-based” (baseados em Unix), todos os usuários do sistema tem um shell associado a sua conta de usuário. Isso quer dizer que se você é um usuário Linux, você possui nas configurações de sua conta pessoal no sistema um interpretador shell padrão que será utilizado quando você abre um terminal na interface gráfica, ou quando faz o login no sistema em modo texto. Por serem o bash e o sh compatíveis, e praticamente o padrão usado nas atuais distribuições Linux, usarei o bash como referência em dicas e comandos desse post.

O bash permite execuções de comandos e expressões regulares (pretendo abordar futuramente) direto no prompt do sistema ou escritas sequencia em arquivos de texto (que você pode criar com qualquer editor de texto puro de sua preferência) conhecidos como shell scripts (ou bash scripts no caso específico deste interptetador). Para que um bash script possa ser executado, o mesmo deve receber atributo de executável, através do comando chmod:

su -c chmod +x nomedoseuscript

O su -c é necessário para que você execute o comando em nível de superusuário (root).
Pronto. Feito isso, seu arquivo já se tornou um script executável através da linha de comando.
Basta digitar, no diretório em que seu script está:

./nomedoseuscript

Segue um exemplo bem simples de bash script:

#!/bin/bash
#o comando abaixo exibirá uma variável global de ambiente
echo "Olá $USER"
echo "O diretório pessoal de sua conta de usuário é $HOME"
echo "Você está utilizando o interpretador de comandos $SHELL como sua shell"


Esse exemplo representa bem a indicação do interpretador de comandos a ser utilizado pelo bash script (que ocorre na primeira linha do script), e a utilização de uma variável de ambiente para exibir informações como o nome do usuário ($USER) que logou no sistema na sessão em que o script foi executado, o diretório pessoal ($HOME) do usuário logado, e o caminho e nome do interpretador de comandos ($SHELL) que está sendo utilizado. Podemos notar também uma linha de comentário no exemplo, que utiliza o # no início da linha pra dizer ao interpretador de comandos para ignorar a linha (lembre-se que o interpretador não ignora o #! pois ele indica, logo no incício do script, o interpretador a ser utilizado).
Aproveitando ainda o exemplo, vou falar um pouco sobre variáveis de ambiente… São variáveis presentes no seu ambiente shell, que permitem que você resgate valores específicos que estão associados a elas, tais como seu nome de usuário, nome de sua máquina, interpretador shell padrão de sua conta de usuário, seu path (path é uma lista de diretórios onde seu sistema procura por arquivos executáveis para que você possa executá-los diretamente de qualquer outro diretório sem fazer referência ao caminho completo onde os mesmos se encontram), sua home (diretório pessoal de sua conta de usuário), e muitos outros valores, que também podem ser atribuidos em variáveis definidas durante a execução de seu próprio script. Para obter uma lista completa das variáveis que estão atualmente declaradas em seu ambiente, você pode utilizar o comando env combinado com o comando less, conforme o exemplo abaixo:

env | less

O comando env mostra todas as variáveis declaradas no ambiente, e o comando less serve para apresentar o resultado do primeiro comando de maneira que usuário possa “navegar” pelo texto com as setas do teclado em casos em que o resultado a ser exibido na tela excede o limite de linhas que o usuário consegue ver simultaneamente em seu monitor ou janela de terminal. Já o | (pipe) serve justamente para combinar dois ou mais comandos. Ele conecta a saida padrão do comando anterior com a entrada padrão do próximo comando. Vamos observar outro exemplo da utilização do pipe:

cat ~/casa.txt | grep movel

O comando cat serve para exibir na tela o conteúdo de um arquivo. Neste caso, o | (pipe) está conectando a saída do comando cat com a entrada do comando grep, que por sua vez serve para procurar dentro de um determinado conteúdo e exibir as linhas que contenham o termo especificado no comando. Pra quem não sabe, o ~ (tio) serve apenas para designar de maneira mais rápida e prática o caminho do diretório pessoal do usuário que está executando o comando… Portanto, se você está logado como juca, escrever o ~ no comando é o mesmo que escrever /home/juca. O resultado desse comando portanto será a exibição na tela de todas as linhas que contenham a palavra “movel” dentro do arquivo “casa.txt” localizado no diretório pessoal do usuário que executou o comando. Simples não?

Aproveitando que estamos tratando de alguns comandos Linux/Unix, segue abaixo uma lista dos principais e mais importantes comando que você pode usar na shell, com suas respectivas finalidades:

ls – lista o conteúdo do diretório;
cd – vai para um determinado diretório;
cp – copia arquivos ou diretórios (para copiar diretórios, usar a opção -r);
mv – move ou renomeia arquivos ou diretórios;
rm – deletar arquivos ou diretórios (para deletar diretórios, usar a opção -rf).
mkdir – cria diretórios;
rmdir – deleta diretórios;
ln -s – cria links simbólicos (symlinks) para arquivos ou diretórios;
file – determina o tipo de um arquivo;
cat – exibe o conteúdo de um arquivo;
head – exibe as primeiras linhas de um arquivo;
tail – exibe as últimas linhas de um arquivo;
less – lista o conteúdo de um arquivo permitindo que o usuário “navegue” pelo seu conteúdo para poder ler arquivos grandes;
more – funciona como o less, porém em vez de navegar linha a linha, o more mostra página por página fazendo pausas ao fim de cada uma;
man – exibe instruções de utilização de um comando;
reboot – reinicia o sistema;
shutdown -h now – desliga o computador;
stty -a – lista configurações do terminal;
w – exibe informações gerais sobre usuários logados e seus processos ativos;
who – exibe informações dos usuários atuais (utmp);
last – exibe o histórico de logins no sistema (/var/log/wtmp);
lastlog – exibe informações sobre últimos logins;
df -h – exibe o espaço livre e ocupado nas partições do sistema;
du -sh – exibe o espaço ocupado pelo diretório e seus subdiretórios;
free – exibe informações sobre a ocupação da memória RAM e swap;
vmstat – exibe o status da memória virtual (processos, cpu);
lsdev – exibe uma listagem do hardware da máquina;
lspci – exibe uma listagem dos dispositivos de hardware PCI da máquina;
lsusb – exibe uma listagem dos dispositivos de hardware USB da máquina;
pnpdump – exibe informações sobre as placas ISA PnP da máquina;
lsmod – exibe informações sobre módulos na memória;
rmmod – remove módulos da memória;
procinfo – exibe informações sobre os processos ativos na máquina (funciona como o comando cat /proc )
top – mostra em tempo real informações sobre os processos ativos e seu consumo;
xdpyinfo – exibe informações sobre o servidor X (servidor gráfico);
showrgbq – exibe o banco de dados das cores RGB com seus respectivos nomes;
xlsfonts – exibe o nome das fontes reconhecidas pelo servidor X;
xset – ajusta certos parâmetros do servidor X, tais como screen-saver, velocidade do mouse, etc;
jobs – exibe os processos rodando em background e em foreground;
bg – manda um processo ativo para background;
fg – manda um processo em background para foreground;
nice – altera prioridade de um processo;
renice – altera prioridade de um processo;
ps -auxw – lista todos os processos do sistema:
time <comando> – executa um comando calculando o tempo decorrente entre o início e o fim desse comando;
kill <id> – mata um determinado processo;
killall <id> – mata um determinado processo (também pode ser utilizado com o nome do processo ao invés da ID;
kill -HUP <id> – reinicia um determinado processo (também pode ser utilizado com o nome do processo ao invés da ID;

Bem, esses são os comandos mais importantes. Gostaria de ressaltar que o comando man <nome_do_comando> serve justamente para que você aprenda melhor a utilizar qualquer um desses comandos.

Lembre-se também, que você pode concatenar comando utilizando o | (pipe) ou o && ( “e” comercial) como foi dito antes, e você pode também utilizar redirecionamentos, tais como o > e o >> . Vou exemplificar como funciona na prática…

ls /home/juca > lista.txt

Esse comando irá criar o arquivo lista.txt cujo conteúdo será o resultado do comando ls /home/juca . Ou seja, o redirecionamento > fez com que o resultado do primeiro comando fosse direcionado para o arquivo especificado após o > . Agora você tem um arquivo lista.txt que contém uma lista em texto com o conteúdo do diretório /home/juca. Simples não?

Já se você utilizar o comando:

ls /home/juca/imagens >> lista.txt

Você irá, com esse redirecionamento ( >> ) concatenar no fim do arquivo lista.txt, o resultado do comando ls /home/juca/imagens… Ou seja, este novo redirecionamento não vai criar o arquivo, mas sim adicionar o resultado do primeiro comando no final do arquivo já existente.

Simples não?

Agora vamos falar um pouco sobre metodos de localização de arquivos via shell no Linux… Segue uma lista com os principais comandos para esse propósido:

updatedb – Cria ou atualiza um banco de dados com informação sobre todos os arquivos e diretórios presentes no sistema (deve ser executado com permissões de super-usuário / root);

locate <arquivo> – localiza um determinado arquivo ou diretório no sistema, e exibe o caminho completo de sua localização;

find – localiza arquivos em locais determinados de acordo com vários critérios, como por exemplo:

find /home/juca -name “*.jpg” – Exibe todos os arquivos de extensão jpg localizados no diretório /home/juca;

find /home/juca -size +3000k – Exibe todos os arquivos do diretório /home/juca que possuem mais de 3MB de tamanho;

E assim por diante…
Segue agora uma pequena lista de comandos utilizados para manipular informações em arquivos de texto:

diff – compara dois arquivos;
ispell -d br – verfica ortograficamente um arquivo de texto utilizando o dicionário em português;
sort – ordena um arquivo de texto (em ordem alfabetica, crescente, etc. – lembre-se que, assim como na maioria dos comandos de manipulação de texto, você pode utilizar sort arquivo > arquivo2 para criar um segundo arquivo com o resultado ordenado… ou seja, usar redirecionamento para que a exibição do resultado do comando seja jogada pra dentro de um determinado arquivo);
uniq – exibe um arquivo de texto removendo linhas duplicadas da exibição;
cut – exive uma área delimitada de um arquivo de texto (exemplo: cut -c3 exibe o terceiro caracter do texto);
wc – conta linhas, palavras e bytes de um arquivo de texto;
fold – ajusta o arquivo de texto para uma largura determinada;
nl – exibe as linhas de um arquivo de texto numeradas;
fmt – reformata linhas de um arquivo de texto;
expand – converte os espaços de um arquivo de texto em tabulações;
unexpand – converte as tabulações de um arquivo de texto em espaços simples;
tr – remove ou substitui caracteres de um arquivo de texto (exemplos tr -d j-m remove todas as letras que ficam entre o j e o m no alfabeto do arquivo… tr n-p N-P torna todas as letras entre o n e o p no alfabeto maiúsculas…);

Bem, este post já está ficando muito longo, e acredito que o que foi dito até agora já deve dar um empurrãozinho para aqueles que gostariam de aprender mais sobre a shell, e sobre a utilização de comandos em modo texto no Linux ou em outros sistemas Unix-based…

Para quem quiser se aprofundar no assunto, recomendo MUITO qualquer tipo de material do nosso amigo Aurélio Marinho Jargas (@oreio – twitter), Brasileiro, ESPECIALISTA em shell scripting, expressões regulares, e desenvolvimento de software. Além de ter publicados ótimos livros sobre shell scripting e expressões regulares, o Aurélio nos presenteou a todos com o famoso Canivete Suíço do Shell, que é o tipo de leitura PERFEITA pra você que quer estudar sobre o assunto.

Espero que tenham gostado.

Um grande abraço a todos e até a próxima.

A estrutura primária (ou básica) de diretórios engloba todos os diretórios que estão diretamente ligados ao diretório raiz do sistema, ou seja, o diretório / , que é o ponto de origem de todos os subdiretórios do sistema.

As distribuições baseadas no Debian (optei por tratar delas por serem bem populares) seguem basicamente a estrutura padrão de diretórios Unix, regulada pela norma FHS (Filesystem Hierarchy Standard – http://www.pathname.com/fhs), sendo que existe também uma adaptação específica para os sistemas operacionais GNU/Linux… a LFH (Linux Filesystem Hierarchy – http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/) que não tem tanta atenção por parte dos desenvolvedores como a FHS em virtude do nível de padronização que a mesma atingiu.

Como sempre, chega de blá blá blá e vamos logo ao mais importante… Seguem abaixo os diretórios básicos do sistema GNU/Linux e a descrição de sua função/conteúdo:

/bin – É o diretório onde ficam armazenados os arquivos BINários (óbvio, não?) executáveis, que podem ser executados pelos usuários do sistema;

/boot – É o diretório que contem a imagem do Kernel Linux e os arquivos de boot do sistema, bem como o gerenciador de boot que você usa em sua máquina. Esta pasta deve ser estudada com especial atenção, pois qualquer alteração feita indevidamente em seu conteúdo pode comprometer a inicialização do sistema. É dentro desse diretório que se localiza o grub (gerenciador de boot utilizado pela grande maioria dos usuários de distribuições GNU/Linux atuais);

/cdrom – Não é propriamente um diretório, mas sim um link para o diretório /media/cdrom (ponto de montagem do dispositivo leitor de CD/DVD da máquina;

/dev – É o diretório que contém os device drivers do sistema, ou seja, contém os arquivos que servem de ligação com os dispositivos de hardware da máquina;

/etc – É o diretório que contém quase todos os arquivos de configuração do sistema operacional GNU/Linux.

/home – Como o próprio nome já diz, é a “casa” do usuário dentro do sistema. Ou melhor, eu chamaria de condomínio dos usuários no sistema, já que dentro dele estão os subdiretórios individuais de cada um dos usuários do sistema, onde se encontram todas configurações e documentos pessoais de cada usuário. Ele é a base para os diretórios próprios de cada usuário. Se o seu nome de usuário no sistema é abigobaldo (tomara, Deus, que seus pais não tenham feito isso com você ), por exemplo, seu diretório pessoal é /home/abigobaldo . Cabe ressaltar que ao logar-se no sistema, você pode acessar seu diretório pessoal no terminal simplesmente com o comando cd ~ , já que o sistema interpreta o ~ (tio) como /home/seudiretóriopessoal;

/initrd – Este diretório é utilizado pelo Kernel Linux durante o boot como um HD virtual criado na memória RAM da máquina (um RAM disk);

/lib – Neste diretório estão os módulos e libraries (bibliotecas) do Kernel Linux utilizadas durante o boot do sistema e também utilizadas por arquivos executáveis do sistema após o boot.

/lost+found – Este diretório pode não estar presente na sua máquina se você procurar por ele agora, e isso é um bom sinal. Esse diretório é criado apenas quando sistemas que utilizam filesystems jornalados (leia mais a respeito no post de Introdução ao sistema GNU/Linux) tem que fazer uma recuperação de filesystem após um problema (normalmente desligamento abrupto da máquina por queda de energia). É nesse diretório que são colocados os arquivos que puderam ser encontrados e recuperados após um problema com o filesystem, porém, eles são colocados lá sem seu nome original, que possuíam antes da falha.

/media – É o diretório base de todos os mount-points (pontos de montagem) de mídias removíveis do sistema, tais como disquetes, HDs USB portáteis, Pendrives e CDs;

/mnt – É um outro diretório base de pontos de montagem, porém para este existe a convenção de se montar dispositivos fixos da máquina nele, como seu HD interno, por exemplo. Mas nada impede que você monte uma mídia removível ou até mesmo um diretório qualquer de outra máquina da sua rede local neste diretório;

/opt – Se verificar o conteúdo deste diretório, MUITO provavelmente ele estará vazio. A idéia inicial deste diretório era armazenar programas que não fizessem parte da distribuição GNU/Linux instalada em seu sistema, porém, esse método de separação não é amplamente utilizado;

/proc – Não é bem um diretório. Trata-se de um filesystem virtual, cheio de arquivos virtuais, que na verdade são apenas referências dinâmicas dos procedures (procedimentos) do Kernel Linux, que são alteradas constantemente durante a utilização do sistema;

/root – O diretório do mandachuva… do big boss do sistema. Esse é o diretório do superusuário do sistema (pode chamar de administrador se quiser). O único usuário do sistema com permissão para realizar qualquer modificação no sistema. Aí você me pergunta: “Mas Marco, se é uma pasta de usuário, porque não está dentro de /home ?”. E eu explico: É conveniente durante a instalação do sistema, determinar que o diretório /home seja montado em uma partição separada da partição principal (onde estão os demais diretórios do sistema), para fins de backup e organização. Se o diretório root estivesse nessa partição separada (dentro de /home) e ocorresse com essa partição o que costumo chamar de um “momento PUTZ… FODEU!”, o diretório /root também estaria inacessível, e como você já sabe, certas coisas só podem ser feitas ou desfeitas no sistema pelo usuário root… Então você não poderia, por exemplo, inicializar o sistema para realizar uma recuperação nessa partição;

/sbin – O nome vem de System BINnaries. Este diretório, assim como o /bin, armazena arquivos binários executáveis, porém nele ficam os executáveis relacionados com a manutenção e administração do sistema, sendo que a grande maioria deles só podem ser executados pelo superusuário (root), salvos alguns casos, como o ifconfig, por exemplo, que pode ser executado por outros usuários (em algumas distribuições Linux, isso não ocorre), porém com a especificação completa de localização (ou seja, incluindo o endereço completo – /sbin/ifconfig) já que nas variáveis de PATH (variável que indica ao sistema onde procurar por arquivos cujos endereços completos não são especificados pelo usuário no momento da execução do comando) dos usuários comuns não estão os diretórios /sbin e /usr/sbin;

/srv – É um diretório que sofre do mesmo problema de esquecimento e solidão que o diretório opt, pois não é utilizado por muitas distribuições… A idéia inicial era usá-lo para armazenar dados que seriam disponibilizados por qualquer programa servidor que você utilizasse no sistema, mas foi outra idéia que “não pegou”. Apesar disso, em meu servidor pessoal, optei por manter /srv como o diretório que hospeda os arquivos a serem servidos pelo Apache (servidor http que utilizo);

/sys – O nome vem do sysfs (sys filesystem). É o diretório usado pelo Kernel Linux para manter dados atualizados sobre os dispositivos de hardware da máquina (não confunda, não é a mesma coisa que /dev, já que no /dev estão arquivos que servem de ligação com os dispositivos, e não informações sobre eles);

/tmp – É um diretório utilizado pelo sistema para armazenar informações temporárias, que são apagadas quando você reinicia o sistema. Portanto, não arrisque colocar sua pasta de documentos profissionais ai dentro BAZINGA! ;

/usr – É o diretório que armazena todos os dados “não críticos” (entenda-se não essenciais para o funcionamento da base do sistema) do sistema operacional. Ele também contem arquivos executáveis nos subdiretórios /usr/bin e /usr/sbin, porém, não são arquivos necessários para uma inicialização mínima do sistema num momento “putz… fodeu!”, e por isso, podem ser armazenados nestes diretórios. O termo usr não vem de users como muitos pensam, mas sim de Unix Shared Resources (Recursos Compartilhados Unix). É nesse diretório que ficarão praticamente todos os programas que você instalar através do gerenciador de pacotes da sua distribuição Linux;

/var – Este diretório armazena os dados VARiáveis do sistema (não confunda com dados temporários do /tmp pois estes não são apagados a cada inicialização do sistema). Dentro deste diretório estão todos os logs do sistema (no subdiretório /var/log), assim como o spool de impressoras do sistema, spool de cache http (squid), e outras coisas. Caso você tenha um WebServer ou um MailServer ativo em seu sistema, é dentro do diretório /var que, por padrão, vão ficar os dados acessíveis. Por exemplo, se você instalar o servidor web Apache2, as páginas que serão disponibilizadas (servidas) pelo programa estarão em /var/www por padrão na maioria das distribuições Linux.

Pronto… Agora você já conhece um pouco sobre a estrutura básica de diretórios do sistema operacional GNU/Linux, e já deve estar bem mais familiarizado com o sistema. Cabe ressaltar que dos diretórios mencionados, os seguintes são utilizados diretamente durante o boot do sistema, e por isso tem que estar “íntegros”:

bin, boot, dev, etc, initrd, lib, proc, root, sbin

Portanto não permita nunca que ocorra um momento “putz… fodeu!” com nenhum desses diretórios, pois se ocorrer, você vai enfrentar na verdade um momento “PUTZ… fodeu MESMO!!!”.

Espero ter esclarecido mais um pouco sobre o sistema operacional para os usuários iniciantes do mundo Linux.

Por hoje é só pessoal!

A grande vantagem do Kernel Linux é que muitas funções podem ser compiladas e executadas como módulos (LKM – Loadable Kernel Modules ou Módulos Carregáveis do Kernel), que são bibliotecas compiladas separadamente da parte principal do Kernel e podem ser carregadas e descarregadas pelo sistema mesmo com o Kernel já estando em execução (pra quem não sabe, compilar um programa ou módulo é basicamente “fazer com que um compilador o reescreva, já interpretado”, para transformar as instruções de alto nível  (linguagem mais próxima da linguagem humana) nele contidas em instruções de baixo nível (linguagem “de máquina”), para que não ocorram, durante a execução do mesmo, perdas de tempo com interpretação de instruções).

Outra característica fantástica do Kernel Linux é sua portabilidade, que permite que o mesmo seja utilizado em sistemas mínimalistas (como celulares e palmtops) até sistemas de enorme porte, como densos mainframes. Por outro lado, temos também a enorme portabilidade no sentido do Kernel ser extremamente compatível com uma imensa variedade de fontes que podem ser compiladas e utilizadas em Linux.

.

Como funciona o Kernel…

1- Os filesystems (sistemas de arquivos)

Filesystem, ou sistema de arquivos, é o sistema utilizado pelo Kernel Linux para organizar, acessar e escrever os arquivos nos discos ou mídia de armazenamento disponível no sistema. Ou seja, é um artifício usado pelo Kernel para controlar a gravação e leitura dos dados (no seu disco rígido, por exemplo).

Existem vários tipos de filesystems, sendo que os mais conhecidos para GNU/Linux são:

- os baseados em discos -> Ext2, Ext3, ReiserFS, XFS, JFS e ISO 9660;

- os baseados em rede -> NFS, SMBfs, Coda e AFS;

- os filesystems especiais -> Utilizados em diretórios como o /proc, ramfs e devfs.

Cada filesystem tem suas especificações, tais como tamanho de blocos (ou espaços delimitados destinados ao recebimento dos arquivos) e técnicas especiais de recuperação em caso de falhas.

- Filesystems “jornalados” ou journaling filesystems, são filesystems que utilizam técnicas de recuperações em caso de falhas (como desligamentos abruptos, queda de energia e outros tipos de desastre de sistemas de arquivos). A expressão “journal” está ligada à ideia de se manter um log ou registro de eventos realizados no filesystem.

Os sistemas de arquivos com journaling mais utilizados atualmente em sistemas operacionais GNU/Linux são: o ReiserFS (criado por Hans Reiser), o Ext3 (criado por Stephen Tweedie), o XFS (criado pela Silicon Graphics) e o JFS (criado pela IBM). Minha opção pessoal é o ReiserFS, que além de muito seguro e de fácil recuperação em caso de desastres, se mostra atualmente mais eficiente ao trabalhar com arquivos pequenos e tão eficiente quanto aos demais ao trabalhar com arquivos grandes, por realizar a distribuição dos arquivos nos blocos de uma maneira mais inteligente sob meu ponto de vista.

O sistema GNU/Linux atualmente também é capaz de ler e escrever no sistema de arquivos NTFS (sistema de arquivos proprietário da empresa microsoft).

Em meu próximo post, irei explicar detalhadamente a estrutura de diretórios usada pelos sistemas operacionais GNU/Linux, porém, ainda neste tópico, falarei um pouco sobre o diretório /dev (responsável pela ligação entre o Kernel Linux e os dispositivos de hardware do sistema) e quero agora também explicar o que contem o diretório /proc -> diretório de um filesystem especial virtual que contém referências a informações dinâmicas dos processos do sistema, geradas constantemente pelo Kernel Linux.

.

2 – Operações I/O ou E/S (In/Out ou Entrada/Saída)

São as operações de comunicação do Kernel Linux com os dispositivos de hardware da máquina. As operações de entrada e saída realizadas pelo Kernel Linux são implementadas através dos device drivers, ou seja, para cada dispositivo de hardware da máquina, existe um device do Kernel (arquivo que serve de ligação com os dispositivos de hardware, criado pelo Kernel no diretório /dev do filesystem (sistema de arquivos)).

O Kernel Linux realiza todas as operações de E/S com uma sequëncia de bytes, sem qualquer conceito de registro ou métodos de acesso. Dessa forma, ocorre uma comunicação mais direta com os dispositivos de hardware, de maneira uniforme. O Kernel pode acessar e escrever nos arquivos de ligação do diretório /dev (ou devices do Kernel) da mesma forma que ocorre em qualquer outro arquivo do filesystem, utilizando chamadas do sistema (system calls) de leitura e gravação.

O Kernel Linux trabalha com dois tipos de operações de E/S: orientadas a blocos e orientadas a caracter. As operações orientadas a bloco são geralmente utilizadas em dispositivos com uma taxa alta de transferência de dados (como por exemplo discos rígidos) fazendo com que seja reduzido o número de transferências necessárias entre o device do Kernel e a memória, já que em cada tranferência de dados são enviadas várias informações simultaneamente em blocos (agrupamentos). Já os dispositivos de hardware mais lentos, ou que demandam uma transferência menor de dados, são orientados a caracter, ou seja, a transferência entre o dispositivo e a memória são realizadas caracter a caracter.

.

3- Gerenciamento de memória

Entenda que quando executamos aplicativos ou funções do sistema operacional, o processador da máquina executa trocas dinâmicas com a memória principal do sistema (memória RAM). Isto ocorre pois o processador precisa armazenar as informações que recebeu para processá-las aos poucos de acordo com sua capacidade. O subsistema de gerenciamento de memória do Kernel Linux, preocupa-se especialmente com alguns fatores responsáveis pelo correto e eficaz gerenciamento dessas trocas dinâmicas.

Os principais aspectos do gerenciamento de memória são:

- Utilização de memória e swapping: O Kernel Linux sempre utiliza a maior quantidade de memória RAM possível, já que quando executamos um programa qualquer, tornando-o um processo do sistema, ele armazena temporariamente na memória RAM os dados necessários à sua execução, e esses dados não são apagados imediatamente após o encerramento de sua execução. Eles permanecem carregados na memória o máximo de tempo possível, pois caso o mesmo processo seja executado novamente em breve, os dados ainda estarão lá disponíveis, agilizando muito a execução. Essa técnica de manter os dados de programas executados na memória RAM chama-se Buffer Cache, e é utilizada para os dados que são utilizados pelos device drivers (drivers de dispositivos de hardware de que falamos acima em operações E/S). O Buffer Cache só é apagado parcialmente ou totalmente da memória RAM quando não há mais espaço suficiente para carregar um novo programa, e os dados escolhidos a serem apagados são aqueles que estão há mais tempo sem serem acessados, o que mostra ao Kernel que eles provavelmente não serão mais utilizados tão breve. Esse método de escolha é chamado de swapping, que utiliza um conceito de “envelhecimento” de informações conforme as mesmas não são utilizadas, e “rejuvenecimento” de informações conforme as mesmas são acessadas (não confundir swapping com memória virtual ou swap).

- Proteção: O Kernel Linux divide e separa os processos carregados na memória RAM da máquina como processos do kernel e processos do usuário

- Mapeamento de memória: Os processos em execução no sistema são divididos em páginas e somente algumas dessas páginas estão realmente na memória física do computador. Outras delas são “endereços virtuais” que agilizam o processo de acesso da memória. A utilização de endereços virtuais com endereços reais (físicos) de memória é chamada de mapeamento de memória. Todos os processos tem referências em uma estrutura de dados chamada pelo Kernel Linux de “mm_struct”. Esta estrutura contém informações sobre o que está sendo executado no momento e possui apontamentos para uma outra estrutura de dados chamada “vm_area_structure”, que contém “o endereço” de todos os PFN (Page Frame Numbers – que podemos entender de maneira menos técnica como o “endereço” ou localização exata de onde estão realmente as informações na memória do computador).

- Alocação: O Kernel Linux utiliza o algoritmo Buddy (Companheiro – nome pelo qual é conhecido o algoritmo de alocação) para alocar e desalocar páginas de memória utilizando blocos de páginas. O gerenciamento de memória do Kernel aloca e desaloca páginas de memória com extremo dinamismo, causando assim uma fragmentação de memória, que é resolvida pelo Kernel com um processo de desfragmentação que junta espaços preenchidos de memória que são categoricamente semelhantes.

Memória Cache: É utilizada para otimizar e agilizar o acesso a informações. Exemplos de Cache utilizadas pelo Kernel Linux: Buffer Cache (vimos acima quando falei de operações E/S – são blocos de tamanho fixo usados por device drivers que agilizam o acesso a informações que já estejam nesse buffer, tornando desnecessário o acesso direto ao dispositivo de hardware), o Page Cache (usado para tornar mais rápido o acesso a vários tipos de informação no disco), e o Swap Cache (que faz com que apenas páginas de memória modificadas sejam salvas na memória virtual física (que veremos abaixo) sendo que as páginas de memória inalteradas com seu acesso podem ser descartadas sem a necessidade de gravá-las fisicamente).

Memória Virtual: Memória virtual ou memória SWAP é um recurso utilizado pelo Kernel Linux que consiste em reservar uma parte da memória secundária da máquina (o disco rígido), especificada pelo usuário, para ser uma extensão da memória primária (memória RAM). O conceito de memória virtual está, ao contrário do que muitos pensam, ligado ao produto final da junção entre a memória primária e o espaço reservado da memória secundária. Ou seja… A memória virtual = Memória RAM + Memória SWAP. O processador transfere os dados do processo que está executando diretamente para a memória RAM (primária). Quando surge a necessidade de esvaziamento de parte da RAM para executar outro processo (e surge mesmo, pois lembre-se que o Kernel Linux utiliza sempre o máximo de memória possível devido ao Buffer Cache, para agilizar os processos), alguns processos existentes, mais envelhecidos (pelo swapping) que estiverem esperando para continuar sua execução, são transferidos para a o disco rígido, para a parte reservada à memória SWAP. Para que esse recurso possa ser utilizado, uma partição deve ser criada no disco durante a instalação do sistema operacional e especificada (reservada) como partição SWAP. O tamanho ideal para uma partição swap é um assunto que merece atenção exclusiva, e por isso, falarei sobre isso e sobre planejamento de particionamento num próximo post.

.

4- Agendamento de processos

Primeiramente vamos esclarecer de uma ver por todas o que é processo. Processo é uma instância de um programa em execução. Todo processo tem um pai (ou processo criador) e um número único atribuído pelo Kernel no momento de sua execução, que o identifica no sistema… o PID (Process Identifier). Para fazer um planejamento e compartilhamento adequado do tempo do processador, o Kernel Linux usa um sistema de 2 tipos de classificação, que avalia cada processo e lhe atribui qualidades que permitem que seja determinada uma prioridade de execução para cada processo avaliado. Os processos são classificados pelo Kernel quanto a sua responsividade (ou seja, se o processo responde em tempo real, interativo ou em segundo plano) e quanto a sua intensidade de atividade (ou seja, se o processo utiliza muito tempo de processador (CPU-Bound ou Limite de CPU) e se faz muitas operações de E/S (I/O-Bound ou Limite de Entrada e Saída)). Essas duas classificações são relativamente independentes, ou seja, um processo pode, por exemplo, ter uma baixa responsividade (como um daemon por exemplo, executado em segundo plano) e ao mesmo tempo ter uma grande intensidade de atividade (ou seja, ter um grande consumo de operações de E/S)… Podemos citar como o exemplo o caso do Servidor Web Apache2 servindo um banco de dados MySQL. Avaliadas essas classificações, o Kernel Linux utiliza seu sistema de prioridades e organiza os processos. A identificação da prioridade de um processo pode ser estática ou dinâmica, e varia de 1 (maior prioridade) a 139 (menor prioridade), sendo que os números de 1 a 99 são atribuídos a processos executados em tempo real, e de 100 a 139 são atribuidos a processos tradicionais (processos interativos ou processos executados em segundo plano).

Os processos executados em tempo real são classificados como FIFO (First-In, First-Out) ou RR (Round-Robin), e eles somente passam a ser excluídos do processamento atual nos casos de: fim de sua execução; para ser substituído por um processo que possua prioridade ainda maior; executar uma operação de bloqueio; espontaneamente pelo próprio processo; quando o processo é RR (Round-Robing) e esgotou seu quantum de processamento.

Um processo tradicional (processos interativos e os executados em segundo plano) tem inicialmente uma prioridade estática atribuída (normalmente 120) que determina o seu quantum de processamento, mas pode ter uma prioridade dinâmica, que é o valor analisado pelo agendador de processos do Kernel quando percorrer a lista de processos para determinar de qual processo é a vez de utilizar o processador. A prioridade dinâmica pode alterar o valor da prioridade estática em + ou – 5 pontos dependendo do passado do processo (lembre-se que quando menor a pontuação, maior a prioridade do processo). Ou seja, o passado do processo irá beneficiá-lo caso o mesmo tenha ficado muito tempo esperando por sua execução fora do processador (sleep time). Caso o sleep time seja pequeno, o processo irá ser penalizado, ou seja, seu número de prioridade irá aumentar, tornando sua prioridade de execução menor.

Por hoje é só pessoal. =)

A Free Software Foundation (FSF), é uma organização sem fins lucrativos com base em Boston (MA – USA), fundada em 1985 por Richard Matthew Stallman, que se dedica à preservação, proteção e promoção da liberdade de usar, estudar, copiar, modificar e redistribuir software para computador, bem como defender os direitos dos usuários de Software Livre. No início de suas atividades a FSF dedicava-se principalmente ao desenvolvimento de Software Livre, porém, com o surgimento de inúmeros projetos independentes de desenvolvimento desse tipo de software, a fundação passou a dedicar-se majoritariamente aos aspectos legais, à documentação das licenças de uso e distribuição de software, e aos aspectos estruturais da Comunidade do Software Livre.

Richard Stallman, no final da década de 1980, no âmbito do projeto GNU da Free Software Foundation, idealizou a GNU General Public License (GNU GPL ou simplesmente GPL), que é a designação da licença para o Software Livre, utilizada pela maior parte dos projetos realmente livres, em grande parte devido à sua adoção para o sistema operacional GNU/Linux. A licença GPL foi originalmente publicada em Janeiro de 1989, porém com o passar do tempo, percebeu-se que sua redação dava margem a vários problemas, tornando necessária sua revisão. Foi o que ocorreu em Junho de 1991, quando foi publicada a GPL versão 2. Em 2005, Richard Stallman anunciou o preparo de uma nova versão da licença em conjunto com Eben Moglen (professor de direito e de história do direito da Universidade de Columbia, fundador, diretor-coselheiro e presidente do Software Freedom Law Center). Depois da publicação de um primeiro esboço em 16 de Janeiro de 2006, foi lançada a versão definitiva da GPL versão 3, em 29 de Junho de 2007. A GPL foi obviamente redigida em inglês, e não possui atualmente nenhuma tradução reconhecida como válida ou oficial pela Free Software Foundation, tendo em vista que qualquer erro de tradução pode deturpar o sentido e verdadeiras intenções da licença. Porém, já existem traduções não oficiais da licença GPL para o português, porém elas são meramente informativas e tem como objetivo auxiliar no entendimento da licença por usuários que não dominam o idioma inglês, mantendo-se assim a obrigatoriedade de se distribuir o texto oficial da licença em inglês com os programas livres licenciados pela GPL.

“Mas afinal de contas, o que é Software Livre?”

De acordo com as definições da própria Free Software Foundation, o software pode ser considerado um Software Livre quando seus usuários possuem todas as quatro liberdades fundamentais, descritas no próprio site oficial da FSF. Essas liberdades são respectivamente:

0- A liberdade de executar o software, para qualquer finalidade ou propósito;

1- A liberdade de estudar como o software funciona, e adaptá-lo às suas próprias necessidades. O acesso ao código-fonte é um pré-requisito para esta liberdade;

2- A liberdade de redistribuir cópias do software para que você possa ajudar outros usuários;

3- A liberdade de aprimorar o software e lançar publicamente seus aprimoramentos, de modo que toda a comunidade possa ser beneficiada com os mesmos. O acesso ao código-fonte é um pré-requisito para esta liberdade.

Como você pode perceber, o usuário de um Software Livre, tem o direito de usar e de redistribuir cópias do software, com ou sem suas próprias modificações, e pode distribuí-lo gratuitamente ou cobrando uma quantia pela distribuição, para qualquer um em qualquer lugar. Ser livre para fazer isso, significa, entre outras coisas, que você não precisa pedir ou pagar pela autorização para fazê-lo. Um Software Livre pode ser utilizado por qualquer pessoa física, pessoa jurídica ou organização em qualquer computador, para qualquer tipo de tarefa ou atividade, sem a necessidade de comunicar ao desenvolvedor ou entidade que o produziu, sem a necessidade de pagar pela sua utilização, e sem a necessidade de atender a quaisquer restrições, tendo em vista que as licenças de Software Livre assim o permitem.

É importante lembrar que a disponibilidade do código fonte do software é indispensável para sua condição de Software Livre, e o mesmo pode ser repassado em versão original ou modificada, com ou sem os arquivos binários ou executáveis gerados a partir desses códigos, sem que seja necessária a autorização do autor ou distribuidor do software. Cada tipo de licença de Software Livre determina como é feito o fornecimento do código fonte para as distribuições. No caso da licença GPL, o código fonte do software deve ser disponibilizado em local onde possa ser acessado por qualquer um, ou deve ser entregue ao usuário quando solicitado, sem custo algum (exceto eventuais custos de mídia e transporte quando necessários), e deve ser distribuido também juntamente com o código-fonte o texto oficial da licença GPL.

Você pode obter um Software Livre gratuitamente ou pagando por ele, mas independente de como você o adquiriu, você sempre terá a liberdade de alterá-lo, de redistribuí-lo gratuitamente e até mesmo de vender cópias, pois o fato de um software ser Livre não significa que esse software não pode ser comercial, já que um Software Livre tem também que, obrigatoriamente, contar com a possibilidade de utilização comercial, desenvolvimento comercial e distribuição comercial. Ou seja, o fato de um software ser Livre, não quer dizer obrigatoriamente que o mesmo é gratuito. Assim como existe o software proprietário gratuito (que não pode ser modificado ou redistribuído sem autorização do desenvolvedor, e que também está sujeito a quaisquer tipos de restrição impostas pela pessoa ou entidade que o produziu), também existe o software Livre comercial (que pode ser vendido, mas que preserva todas as liberdades inerentes ao conceito de Software Livre).

Apesar de as licenças de software livre permitirem que eles sejam vendidos, a grande maioria deles está disponível gratuitamente. Um exemplo disso é a distribuição Red Hat Enterprise Linux, que foi comercializada pela empresa Red Hat, e que, apesar de ser comercial, possui clones gratuitos criados a partir dele disponíveis na web, como por exemplo o CentOS. Uma vez que o comprador do software livre o adquiriu, ele pode redistribuí-lo gratuitamente ou cobrar um preço por sua distribuição.

Também não se pode confundir Software Livre com software de domínio público, tendo em vista que o software livre quando utilizado em combinação com licenças típicas, como a licença GPL ou a BSD, garante a autoria da pessoa ou organização que o desenvolveu. Já no caso do software de domínio público, o autor do software relega a propriedade do programa, e este se torna um bem comum que preserva suas características que o definem como um software livre, ou seja, é um software livre de domínio público (sem reserva de propriedade autoral).

Também não devemos confundir Software Livre com software Open Source (Código Aberto), que são definições ligeiramente diferentes, pois a definição Open Source apenas diz respeito ao código-fonte acessível de um software, mas não quer dizer que o mesmo é obrigatoriamente livre, pois muitos programadores que usam Software Livre, ganham dinheiro desenvolvendo software proprietário de código aberto.

Existem regras ou restrições que podem ser aplicadas no que diz respeito à distribuição de um Software Livre, porém elas não podem nunca conflitar com as liberdades essenciais inerentes ao conceito de software livre que já foram citadas anteriormente. Um exemplo de regra que pode ser aplicada ao software Livre é o Copyleft, que é uma regra baseada na propagação de direitos, utilizada no projeto GNU, que protege legalmente as liberdades essenciais inerentes ao Software Livre, impedindo que sejam criadas quaisquer restrições na redistribuição do software em questão. Ou seja, um software protegido por uma licença GPL com o conceito adicional do Copyleft, se distribuído, preserva a mesma licença, repassando os direitos garantidos pelo desenvolvedor e a autoria do software. Já um software Livre sem Copyleft, pode ser modificado e ter sua versão modificada tornada não-livre caso o usuário que o modificou queira fazer isso.