No conjunto das coisas-que-existem-na-informática-que-na-minha-opinião-que-vale-o-que-vale-não-deviam-existir, em meio a utilizadores, gestores de projecto, bases-de-dados relacionais, frameworks e quejandos, existe uma que nunca tinha referido antes - Sistemas Operativos.
Há muito muito tempo, "more time then I care to remember" como dizia a canção, comecei eu a trabalhar num computador todo jeitoso que na altura era o "state of the art" da indústria, inventado por quem inventou os computadores como os conhecemos hoje. Toda a gente sabe de quem falo - a Xerox, claro está.
Essa maravilha tecnológica chamada Xerox 820-II corria em CP/M, produzido por uma companhia chamada Digital Research que mais tarde ficou tristemente célebre por ter "perdido" o contrato de fornecimento à IBM do sistema operativo para os IBM-PC para o então pouco famoso Bill Gates que soube aproveitar da melhor maneira o facto da sua mãe pertencer ao conselho administrativo de uma instituição de caridade onde também tinha assento o então presidente da... IBM!!! Mas enfim,isso é (outra) história...
Mas, dizia eu, o CP/M era muito bonzinho para trabalhar, uma "footprint" de memória baixíssima (que remédio, pois se não havia memória...), simples o suficiente para, por exemplo, escrever "device drivers" e pequenos utilitários em Assembler praticamente só usando as "system calls" do CP/M (a propósito, fazendo o mesmo em MS-DOS bem que reparei na altura que 80 ou 90% dos System Calls eram iguais).
E o que era melhor, ligava-se o computador e demorava talvez um segundo a carregar todo o OS, desligava-se o computador sem ter cá "shutdowns", fazia-se CTRL+ESC para fazer reboot quase instantâneo. E podia-se correr tudo o que se quisesse em Debug... Incluindo o próprio CP/M. Claro que está que conseguir perceber o programa só olhando para código assemblado e o os registos da CPU era obra...
Mas ainda mais importante, a sua simplicidade permitia compreender o funcionamento do computador, permitia entender directamente essa relação equivoca de software com hardware, entre aquilo que nós como programadores escrevemos e aquilo que a máquina faz ao nível do processador.
Ora eu não defendo que para programar em linguagens de alto nível o programador tenha que necessariamente saber o que se passa a baixo nível, até ao nível do hardware. Aliás, acho que os computadores só marginalmente estão relacionados com a Informática. No entanto, dado que eles são parte integrante do corrente estádio evolutivo da indústria, perceber o que fazem a baixo nível é muito útil seja a que nível se esteja a trabalhar. E eu sou uma pessoa tipicamente de baixo nível...
Bom, mas sendo pequeno é no entanto um OS, e eu comecei por dizer eles que nem deviam existir... É um exagero, claro, só para marcar o meu ponto. Um OS é uma conveniência, às vezes inconveniente. O problema é que quanto maior se torna OS maiores se tornam os inconvenientes, porque cada vez temos um OS "one-size-fit-all", que pode ser bom para a maioria da situações mas que vão sendo cada vez piores quanto mais específicos são os problemas que tentamos resolver. E porque cava-se um fosso cada vez maior entre OS (que é software) e o restante "software aplicacional" que tem que depender daquele, mas que deve ser moldado não às capacidades permitidas pelo OS mas às necessidades do nosso problema.
Idealmente, devíamos ter uma "separação" de níveis somente entre hardware e software , e o que se vê é existirem cada vez mais níveis de separação (que por si só constituem pontos de falha) tal como em HW, OS e SW.
Imaginem em desenvolvimento de software para sistemas críticos como equipamentos hospitalares, aeronáuticos/espaciais, militares e outros, a enorme vantagem que não é poder fazer "debug" de toda a aplicação desde o UI ou outra qualquer fonte de input de dados até a ultima instrução que age directamente sobre o hardware, seja abrir a válvula do oxigénio ao paciente que sufoca, abrir só mais uns milímetros o flap do avião que está em rota de colisão com o nosso, fazer com que o giroscópio na cabeça do míssil alinhe com a gruta onde esta o Bin Laden e não com a casa 500 metros ao lado onde uma família de 150 pessoas está a fazer a festa do primeiro aniversário do mais recente rebento...
Ter todo o software escrito na mesma plataforma/linguagem, de modo a não haver diferenças entre OS e SW aplicacional, parece ser uma ideia boa em teoria, mas funcionará na pratica?
Squeak
Squeak é uma implementação de Smalltalk que corre sobre uma VM que é ela própria escrita em Smalltalk. Foi inventada pelos meus ex-colegas da Xerox PARC, os tais que inventaram o computador como o conhecemos (eu trabalhava na Xerox quando a sede era ali no Parque Eduardo VII, de modos que PARC / Parque, fomos praticamente colegas -- que piada tão gira, não é?) .
SqueakNOS
SqueakNOS é uma tentativa de reduzir ainda mais a dependência de OS do Sqweak, na pratica para 99.9% Smalltalk, 1400 linhas de C e 60 de Assembler.
Squawk
Squawk é uma iniciativa que pretende fazer o mesmo com a JVM que o Squeak fez com o Smalltalk, ou seja, reduzir o mais possível a dependência entre a JVM e o OS.
Bom, para tornar curta uma história longa e antes que mandem dar uma volta larga num cais pequeno, é minha opinião, que mais uma vez repito vale o que vale, que seria de todo conveniente que existissem não um ou dois ou três grandes sistemas operativos mas sim uma grande numero deles, um vasto numero, escritos para casos específicos e de preferência na mesma linguagem das aplicações que vai suportar. Que é como quem diz, não haver OS algum...
Como dizia o outro, isso de ter o OS separado do SW está muito bem na pratica, mas funcionará em teoria?
Bom, e que tal acabarmos com uma músiquinha? Não? Então vamos lá...
Para não roubar largura de banda a outros blogs, podem ouvir (e fazer o download, ler a letra e ver ao vivo) esta música intitulada Every OS Sucks, e que como podem ver pelo refrão simboliza perfeitamente senão o conteúdo, ao menos o espírito deste "post".
Referências:
http://www.artima.com/weblogs/viewpost.jsp?thread=239339
http://blogs.oreilly.com/digitalmedia/2005/10/we-dont-need-no-stinkin-os.html
Há muito muito tempo, "more time then I care to remember" como dizia a canção, comecei eu a trabalhar num computador todo jeitoso que na altura era o "state of the art" da indústria, inventado por quem inventou os computadores como os conhecemos hoje. Toda a gente sabe de quem falo - a Xerox, claro está.
Essa maravilha tecnológica chamada Xerox 820-II corria em CP/M, produzido por uma companhia chamada Digital Research que mais tarde ficou tristemente célebre por ter "perdido" o contrato de fornecimento à IBM do sistema operativo para os IBM-PC para o então pouco famoso Bill Gates que soube aproveitar da melhor maneira o facto da sua mãe pertencer ao conselho administrativo de uma instituição de caridade onde também tinha assento o então presidente da... IBM!!! Mas enfim,isso é (outra) história...
Mas, dizia eu, o CP/M era muito bonzinho para trabalhar, uma "footprint" de memória baixíssima (que remédio, pois se não havia memória...), simples o suficiente para, por exemplo, escrever "device drivers" e pequenos utilitários em Assembler praticamente só usando as "system calls" do CP/M (a propósito, fazendo o mesmo em MS-DOS bem que reparei na altura que 80 ou 90% dos System Calls eram iguais).
E o que era melhor, ligava-se o computador e demorava talvez um segundo a carregar todo o OS, desligava-se o computador sem ter cá "shutdowns", fazia-se CTRL+ESC para fazer reboot quase instantâneo. E podia-se correr tudo o que se quisesse em Debug... Incluindo o próprio CP/M. Claro que está que conseguir perceber o programa só olhando para código assemblado e o os registos da CPU era obra...
Mas ainda mais importante, a sua simplicidade permitia compreender o funcionamento do computador, permitia entender directamente essa relação equivoca de software com hardware, entre aquilo que nós como programadores escrevemos e aquilo que a máquina faz ao nível do processador.
Ora eu não defendo que para programar em linguagens de alto nível o programador tenha que necessariamente saber o que se passa a baixo nível, até ao nível do hardware. Aliás, acho que os computadores só marginalmente estão relacionados com a Informática. No entanto, dado que eles são parte integrante do corrente estádio evolutivo da indústria, perceber o que fazem a baixo nível é muito útil seja a que nível se esteja a trabalhar. E eu sou uma pessoa tipicamente de baixo nível...
Bom, mas sendo pequeno é no entanto um OS, e eu comecei por dizer eles que nem deviam existir... É um exagero, claro, só para marcar o meu ponto. Um OS é uma conveniência, às vezes inconveniente. O problema é que quanto maior se torna OS maiores se tornam os inconvenientes, porque cada vez temos um OS "one-size-fit-all", que pode ser bom para a maioria da situações mas que vão sendo cada vez piores quanto mais específicos são os problemas que tentamos resolver. E porque cava-se um fosso cada vez maior entre OS (que é software) e o restante "software aplicacional" que tem que depender daquele, mas que deve ser moldado não às capacidades permitidas pelo OS mas às necessidades do nosso problema.
Idealmente, devíamos ter uma "separação" de níveis somente entre hardware e software , e o que se vê é existirem cada vez mais níveis de separação (que por si só constituem pontos de falha) tal como em HW, OS e SW.
Imaginem em desenvolvimento de software para sistemas críticos como equipamentos hospitalares, aeronáuticos/espaciais, militares e outros, a enorme vantagem que não é poder fazer "debug" de toda a aplicação desde o UI ou outra qualquer fonte de input de dados até a ultima instrução que age directamente sobre o hardware, seja abrir a válvula do oxigénio ao paciente que sufoca, abrir só mais uns milímetros o flap do avião que está em rota de colisão com o nosso, fazer com que o giroscópio na cabeça do míssil alinhe com a gruta onde esta o Bin Laden e não com a casa 500 metros ao lado onde uma família de 150 pessoas está a fazer a festa do primeiro aniversário do mais recente rebento...
Ter todo o software escrito na mesma plataforma/linguagem, de modo a não haver diferenças entre OS e SW aplicacional, parece ser uma ideia boa em teoria, mas funcionará na pratica?
Squeak
Squeak é uma implementação de Smalltalk que corre sobre uma VM que é ela própria escrita em Smalltalk. Foi inventada pelos meus ex-colegas da Xerox PARC, os tais que inventaram o computador como o conhecemos (eu trabalhava na Xerox quando a sede era ali no Parque Eduardo VII, de modos que PARC / Parque, fomos praticamente colegas -- que piada tão gira, não é?) .
SqueakNOS
SqueakNOS é uma tentativa de reduzir ainda mais a dependência de OS do Sqweak, na pratica para 99.9% Smalltalk, 1400 linhas de C e 60 de Assembler.
Squawk
Squawk é uma iniciativa que pretende fazer o mesmo com a JVM que o Squeak fez com o Smalltalk, ou seja, reduzir o mais possível a dependência entre a JVM e o OS.
Bom, para tornar curta uma história longa e antes que mandem dar uma volta larga num cais pequeno, é minha opinião, que mais uma vez repito vale o que vale, que seria de todo conveniente que existissem não um ou dois ou três grandes sistemas operativos mas sim uma grande numero deles, um vasto numero, escritos para casos específicos e de preferência na mesma linguagem das aplicações que vai suportar. Que é como quem diz, não haver OS algum...
Como dizia o outro, isso de ter o OS separado do SW está muito bem na pratica, mas funcionará em teoria?
Bom, e que tal acabarmos com uma músiquinha? Não? Então vamos lá...
Para não roubar largura de banda a outros blogs, podem ouvir (e fazer o download, ler a letra e ver ao vivo) esta música intitulada Every OS Sucks, e que como podem ver pelo refrão simboliza perfeitamente senão o conteúdo, ao menos o espírito deste "post".
Every OS wastes your time,
from the desktop to the lap,
Everything since Apple Dos,
Just a bunch of crap.
From Microsoft, to Macintosh,
to Lin– line– lin– lie… nux,
Every computer crashes,
’cause every OS sucks.
http://www.artima.com/weblogs/viewpost.jsp?thread=239339
http://blogs.oreilly.com/digitalmedia/2005/10/we-dont-need-no-stinkin-os.html
Comentários
Enviar um comentário