Archive for the ‘sistemas.operacionais’ Category

Acorda, Maria Bonita…

Tuesday, March 13th, 2007

Lendo a revista Mundo .Net deste mês pensei sobre o estado atual das duas maiores plataformas de desenvolvimento modernas, Java e Microsoft .Net. Infelizmente estou tendendo a creditar em uma coisa: A Microsoft aprendeu, a comunidade Java se acomodou. É impressionante como a MSFT tem investido em ferramentas e plataformas interessantes. A estratégia que pude perceber é mais ou menos assim:

  1. Cria-se uma estrutura fundamental baseada em boas tecnologias e plataformas, geralmente copiadas de casos clássicos de sucesso
  2. Pessoas com nível técnico alto utilizam esta base para criar coisas muito interessantes
  3. Pessoas com nível técnico baixo, grande maioria nas duas plataformas, podem utilizar ferramentas burrotizantes que criam apenas o básico que elas acham que precisam

Dado que as pessoas citadas no item (2) são raridade (eu conheço duas, todos vindos de Java/C++),a estratégia de marketing toda foca no povo do item (3). Para o item (2) (para utilizar um termo MSFT: os Elvis e Einsteins) o marketing é baseado em altos salários e oportunidades muito boas em um mercado saturado de arrastadores de componentes (Morts). Com Java foi exatamente o contrário: a linguagem atingiu o jet-set da computação mas logo se banalizou. Einsteins criaram uma plataforma altamente produtiva e de qualidade impressionante, mas logo Mort caíram em cima, fugindo de Delphi e VB 6.0.

Se o programador mediano Java não tivesse tantos problemas no passado com a Microsoft ele facilmente seria seduzido pela plataforma. Ali tem tudo que ele precisa para fazer seus CRUDs (ou seus grudes…). E se Elvis não tivessem tantos problemas com código proprietário e uma plataforma de um vendedor só eles certamente estariam esmagando cabeças dos programadores Java ao comentar como a plataforma .Net está ficando cada vez mais aberta, cada vez mais flexível, cada vez mais… parecida com sistemas em UNIX.

É sério. Não vou nem citar o MS PowerShell, basta olhar como é feito o deployment em .Net e comparar com um sistema UNIX. Ok, eu sei que é muito mais fácil alguém ter visto um deployment .Net que um UNIX então deixe-me tentar explicar com poucas palavras como geralmente é feito um sistema: cada módulo geralmente é implementado como um programa separado (programa mesmo, tipo uma classe com public static void main(String[])), estes programas conversam entre si utilizando diretivas de IPC. O SO (Linux, HP-UX, Solaris, etc.) controla estes programas (feitos em C/C++, PERL, Python, Ruby, Bash, TCL…).

Se você for esperto já fez uma analogia com um servidor de aplicações J2EE. SIM! Os servidores de aplicação vieram solucionar problemas deste modelo, trazendo um nível de padronização (e racionalidade…) para o processamento de transações distribuídas, segurança, persistência, etc. É para isso que Java EE foi criado, infelizmente as pessoas esqueceram ou não tiveram contato com um ambiente não padronizado e não entendem o que é, por exemplo, um EJB. Ok, mas o problema é que o servidor de aplicações é um mundo a parte, e um mundinho bem fechado.

Tem uns dois anos eu trabalhava para uma empresa líder mundial do setor de sistemas para redes de telefonia celular. Esta empresa possui até hoje uns 90% da base de código em C, rodando em Solaris e outros UNIXes. O sistema principal era exatamente como descrevi: um bando de processos em C que se comunicavam via pipes, filas de arquivos e memória compartilhada. parece uma zona, não? Nada de JMS para mensageria, nada de JAAS para segurança, nada de nada.

Pois a grande vantagem deste sistema não era a velocidade, como defendiam os xiitas locais. A vantagem era a flexibilidade. Quando uma correção era implementada o meu colega de baia enviava para o cliente um patch contendo apenas os processos modificados. Quando eu corrigia uma linha de código tinha que mandar um EAR de 10 megabytes. O primeiro nível de suporte era capaz de fazer scripts em PERL e Bash que corrigiam problemas quando aconteciam e automatizavam tarefas para o programa em C. para o programa em java só o próximo release implementaria a mais boba das tarefas, ou uma famosa dedada no banco de dados (um script SQL).

Claro que a culpa é dos programadores (não me excluo) que não se prepararam para sistemas abertos e extensíveis (anos depois eu consegui fazer alguns progressos nesta área e sumarizei em uma palestra), mas o maior problema é na forma que um Application Server é fechado, lacrado. Mesmo os servidores mais modernos ainda contam com abertura precária se comparados aos bons e velhos sistemas UNIX dos anos 70/80/90.

E neste ponto a Microsoft vai na frente, por incrível que pareça. Sua plataforma está baseada em Camadas que são unidas pelo SO, é como se a pessoa pudesse implementar um sistema UNIX utilizando um framework de workflow, persistência, apresentação, comunicação remota, transações e segurança unificado, não importa qual linguagem (e .Net é multilinguagem desde sempre).

Não, eu não estou falando para você migrar para .Net. O que eu estou dizendo é que Java está trilhando caminhos muito perigosos, como desenvolvedores nós temos que ficar de olho. Cuidado com ferramentas milagrosas e,principalmente, cuidado com caixas fechadas (ainda que sejam Open-Source).

E os Einsteins? Eles brincaram com Java mas voltaram para LISP.

Grid+WebServices: Falar e Fazer

Monday, March 20th, 2006

Parece que após tantos e tantos anos de falatório em torno da computação distribuída o início de 2006 traz resultados práticos. A Amazon (é, a dos livros!) anunciou um serviço de armazenamento online e a Sun acaba de anunciar, pela voz do seu presidente, que estará inaugurando uma grid de computadores pública disponível sob demanda.

O Network.com ou Sun Grid ainda vai ser lançado mas pelo que deu para entender você faz o upload de uma aplicação e conecta-se a ela através de WebServices (SOAP, creio). O sistema aceita binários para Solaris x86 ou Java. Mais um dos motivos da Sun para liberar seu Solaris e para se decidir como empresa de hardware, mas hardware como serviço, não como produto.

Em breve creio que vamos ver a IBM e HP lançando serviços parecidos, além de versões baseadas em .Net, Linux, Windows e demais.

A maioria das aplicações que fazemos no dia-a-dia ainda não são o alvo deste tipo de arquitetura. A Sun visa atingir os grandes consumidores de CPU como softwares de simulação, renderização, cálculos e bioinformática. Estas áreas possuem projetos interessantes que ou constroem seu próprio grid e estouram seu orçamento ou não obtêm resultados esperados.

Ainda assim, boa parte das aplicações que eu construí acabaram indo para servidores dedicados em datacenters terceirizados. Se ao invés de alugamors ‘um servidor Pentium IV com Linux’ alugarmos ‘X horas de CPU/mês’, temos um cenário onde grids públicos são bem aplicáveis e, teoricamente, baratos.

Será que em breve fazer deployment de uma aplicação será fazer o upload pro network.com (ou concorrente) dos binários e criar o banco de dados no S3 da Amazon (ou concorrente)?

E a pergunta mais importante neste instante: será que isso salva a Sun?

Windows Inovando Como Sempre…

Tuesday, January 24th, 2006

Essa é imperdível :)

Singularity==UNIX?

Wednesday, December 28th, 2005

Há algum tempo falamos aqui sobre o Singularity, um SO de pesquisa da Microsoft. James Stoup fez uns comentários bem interessantes em seu blog, tem que ligar um pouco o filtro de exageiro (noto uma ceta raiva do Windows Vista no ar…), mas merece uma lida para quem se interessou.

“What would a software platform look like if it was designed from scratch with the primary goal of dependability?” (question found in the MS Singularity research report)Why, it would look like . . . UNIX.

O maior problema do artigo, na minha opnião, é que o Singularity não foi anunciado como um produto, ams apenas como pesquisa, logo se for feito em Sing#, Spec# ou Batatinha#, por exemplo, tanto faz. Um grande mérito da MSFT é em colocar numa pesquisa real alguns conceitos novos para sistemas operacionais.

Isso me lembra o livro que estou lendo. Distributed Systems: Principles and Paradigms, de Andrew S. Tanenbaum Maarten van Steen. Antes de mais nada: sim, eu leio Tanenbaum e gostei muito dos dois livros que li (Redes e Operating Systems: Design & Implementation -que aliás terá uma terceira ediçao em breve).

Eu comecei a ler o livro do mesmo autor chamado Distributed Operating Systems mas não consegui terminar por falta de tempo (está na fila ainda). A parte relacionada é que no Distributed Systems, o autor menciona que este livro era para ser, na verdade, uma nova edição do Distributed Operating System, mas que se generalizou apra sistemas distribuídos de diversos tipos.

O que eu quero dizer com isso? Muitos recursos hoje providos por servidores de aplicação e ambientes de runtime modernos são tão básicos que deveriam estar integrados ao Sistema Operacional. Naming (JNDI, por exemplo), RPC (RMI, CORBA, XML-RPC…), memória gerenciada automaticamente, transações… tudo isso é muito básico. É natural que a arquitetura de hoje evolua e que cada vez mais os Servidores de Aplicação passem essas responsabilidades aos Sistemas Operacionais. Nós não podemos ter aplicações distribuídas e complexas modelo 2006 com sistemas operacionais modelo 1970.

Não, Singularity não é a primeira iniciativa, não é a única e provavelmente não é sequer a mais importante das iniciativas do setor em termos de tecnologia e inovação nos últimos dez anos, porém  é uma iniciativa por uma empresa enorme e que vive de um império baseado em Sistemas Operacionais.

Schwartz Explica a Sun Livre

Monday, December 5th, 2005

John Schwartz falou no seu blog sobre a liberaçao de software como OpenSource.

O ponto dele eh claro e pode ser resumido assim:

The point being, Sun doesn’t have a single customer, worldwide, that will run an unsupported product in their datacenter. Do such customers exist? Surely. They’re called developers. Or startups. Or companies or economies that want to build their own internal support teams…

Opening up Solaris and giving it away for free has led to the single largest wave of adoption Solaris has ever seen - some 3.4 million licenses since February this year (most on HP, curiously). It’s been combined with the single largest expansion in its revenue base. I believe the same will apply to the Java Enterprise System, its identity management and business integration suites specifically. Why?

Because no Fortune 2000 customer on earth is going to run the heart of their enterprise with products that don’t have someone’s home number on the other end. And no developer or developing nation, presented with an equivalent or better free and open source product, is going to opt for a proprietary alternative.

Sun Free Software Foundation

Thursday, December 1st, 2005

O TaQ me passou a notício que passou despercebida ontem, INFO a Sun anuncioou que vai liberar o código dos seus softwares.

Sim, a Sun está transformando todos os seus softwares de servidor em open Source. Por que?

A Sun não anda bem das pernas. Há bastante tempo. Precisa arrumar um jeito de fazer dinheiro. Precisa de volume de usuários.

Quem usa softwares da Sun além do Solaris e JVM? A idéia com o marketing pesado em cima do Netbeans/Java Studio, Open Solaris e tudo mais é atingir mercado.

Todo mundo conhece a esquizofrenia da empresa, que não sabe se ganha dinheiro de software, de hardware, de java, de bananas e por isso acaba não ganhando dinheiro nenhum.

Agora a Sun está mudando oficialmente para uma empresa de serviços. O modelo de licenças está acabado, não dá mais para manter este tipo de produto num mercado como o de tecnologia hoje, a única que consegue faer isso é a Microsoft com seu monopólio e empresas de nicho como Autodesk.

A Sun está no caminho certo na minha opnião, a pergunta é: isso vai realmente ajudar a aliviar o prejuízo da empresa em curto/médio prazo?

Old Fashioned Operating Systems, by Andrew S. Tanenbaum

Thursday, November 10th, 2005

Será este o título apropriado para o clássico livro sobre Sistemas Operacionais do professor Tanenbaum? Certamente sim, e se depender da Microsoft mais cedo do que se pensa. Redmond soltou um paper sobre seu novo sistema operacional, vamos dar uma olhada…

Isso tudo surgiu de uma notícia engraçada que me mandaram sobre o tal paper, o foco não era o SO em si mas sim o fato de que nos benchmarks apresentados os sistemas livres (GNU/Linux e BSD) ficaram na frente do Windows XP na maioria das vezes. Algumas outras fontes publicaram notícias sobre o paper.

Eu adoro meter o pau na MSFT, mas como hobbie apenas. Ocasionalmente saem coisas boas dos laboratórios de Redmond, dos escritórios de negócios e marketing é que não sai nada há muito tempo. Então, vamos avaliar o trabalho divulgado. Primeiro já da pra notar pelas pessoas envolvidas que se trata de algo de alto nível, vale a pena ler o paper.

Singularity é um projeto de SO da Microsoft focado no conceito de dependable systems, pense nisso como sistemas em que se pdoe confiar, de verdade, sistemas seguros não só em privilégios de acesso, senha, comunicação, vírus, invasões,e tc. mas até na forma em que os programas são desenvolvidos, instalados e interagem (o que é o alicerce que sustenta as outras coisas…).

Alguns pontos interessantes:

  • A invariante máxima do sistema é que um processo nunca guarda uma referência para algo dentro de outro processo.
  • O SO possui um modelo muito parecido com as VMs de hoje (JVM ou CLR), com sandboxes e Garbage Collection até mesmo para o kernel.
  • O Kernel é implementado em uma pequena base de código nativo (HAL e VM) e o resto é em C# e uma extensão desta, Sing#, uma extensão(!) de uma outra extensão(!!) de C# chamada Spec# que permite Design by Contract.
  • Uma das idéias é ter um verificador de assembly da aplicação, uma espécie de anti-virus embutido, creio.
  • Não existem Processos como nos SOs normais, mas Software Isolated Processes (SIP), que são anmespaces completos. Cad SIP tem seu próprio GC e um SIP não pdoe mantêr uma referência para um objeto oem outro SIP (o que evita necessidade de GCs sincronizados).
  • A comunicação entre SIPs se dá através de um componente chamado de Exchange Heap (Exchange…esse nome me dá arrepios…). Basicamente um SIP cria uma mensagem, abre uma “conexão” com este outro componente endereçando a outro SIP e passa a cópia da mensagem para o SIP destinatário (ele perde a referência à mensagem), tudo de forma assíncrona.
  • SIPs pais só podem controlar seus filhos quando são criados, antes de rodar e depois que executam. Nunca enquanto seus filhos estão em execução.
  • O Exchange Heap não possui um GC de verdade, apenas um contador de referências
  • Mesmo quando se passa algo ao Kernel, é passado por cópia. A aplicação não tem referência direta ao Kernel, e vice-versa.
  • Existe um serviço de naming como JNDI que oferece uma interface hierárquica única para acessar recursos como FileSystem e Portas de Comunicação.
  • O sistema de segurança é baseado em avaliação de expressões, do tipo “usuario tal + dispositivo X” em vez de ACLs.
  • O agendador (”escalonador”) de Threads é configurável, bem como o GC utilizado no SIP. O sistema possui vários modelos interessantes para threading e fixa que criar e gerenciar estas é pouco custoso em desempenho. Ideal apra um mundo multiprocessador, multicore, multi tudo.
  • A API de chamada ao Kernel (algo como System Calls) é versionada, uma aplicação depende de uma determianda versão para funcionar, se o SO estiver versões a frente, ele oferece uma interface implementando a versão necessária. Tudo pronto para Service Packs :D.
  • Um dos problemas do sistema na minha opinião é tratar a API do kernel através de chamadas estáticas (para uma “Classe” Kernel) o que é equivalente a chamar uma função. Um Kernel OO de verdade poderia fazer mais sentido neste ambiente.
  • As aplicações passam a ser entidades de verdade. Num SO hoje aplicações nada mais são que um conceito, não tem implementação direta no SO. No novo modelo aplicações seriam grupos de recursos unidos por um manifest file, como um arquivo JAR.
  • Os benchmarks mostram resultados muito bons.
  • Um dos pontos marcantes é que não haveria geração de código enquanto o programa roda. Qualquer tipo de código gerado na execuçãod e um SIP geraria outro SIP, não rodaria no original. Isso rpejudica bastante reflection, e uma das alternativas utilizadas é “compile-time reflection”, que é útil quando se sabe o que quer fazer (por exemplo acessar um membro privado de um objeto em Java via reflection) mas bem inútil para aplicações realmente dinãmicas.
  • O sistema de arquivos não é parecido com o WinFS, aliás, nada do Longhorn/Windows Vista aparece aqui

Vale realmente uma lida no paper para entender melhor os aspectos. É impressionante como a tecnologia evolui, há menos de quinze anos Linus Torvalds e Andrew Tanenbaum se engalfinhavam sobre um Microkernel ser viável ou não, hoje temos uma estrutura altamente baseada em linguagens dinâmicas e gerenciadas automaticamente.

É interessante notar que a grande maioria das idéias aplicadas no sistema já existiam muito antes. O Singularity implementa vários recursos como Mensagens Assíncronas, Servidor de Nomes centralizado, VM leve e Garbage Collection que já estão disponíveis fora dos SOs. Como a Microsoft é a única emrpesa que realmente gasta uma grana alta neste ramo de pesquisa, é natural que ela produza resultados na sequência lógica, que é enfiar os serviços que hoje estão disponíveis como middleware no SO.

Apesar de toda a preocupação recente dos funcionário do Tio Bill com segurança, é duvidoso que um sistema deste seja próximo do resultado final. De qualquer jeito é um passo muito grande e é uma pena que um projeto de pesquisa deste não esteja disponível de alguma forma para a academia e comunidade, mas empresas são empresas e colcoar pesquisas que custam dinheiro na mão de outras pessoas pode sair pelo cano.

Há algum tempo atrás (sorry, não achei o link…) eu escrevi sobre como a plataforma Java deveria mudar para concorrer com o Lognhorn (não consigo chamar de Windows Vista!) e seu .Net anabolizado. Muitas idéias que estão no paper do Singularity já foram implementadas ou pensadas no JNode, mas este SO sempre foi mais uma prova de conceito que algo real. A MSFT tem força nos desktops e quer alavancar sua plataforma proprietária de desenvolvimento. A melhor maneira para isso é cada vez mais unir o Windows ao .Net, usando a onipresença de um a favor do outro. O que será que o mundo livre vai oferecer para concorrer com um possível não tão distante sistema operacional em C#? Os debates começaram