Visite também: Currículo ·  Efetividade BR-Mac

O que é LinuxDownload LinuxApostila LinuxEnviar notícia


Lançado o Mono 2.0

“O “Mono Project” acaba de lançar o Mono 2.0; como muitos sabem, o Mono é a iniciativa do Software Livre implementando o “framework” .NET (dot net) na plataforma Linux. O novo lançamento vem recheado de novas caracteristicas, principal (mas não unica) um upgrade” para o C# 3.0. A nota de apresentação mostra todos os detalhes.”

Enviado por irado furioso com tudo (iradoΘsafe-mail·net) – referência (mono-project.com).

“Os desenvolvedores do a Projeto Mono, a implementação de código aberto da plataforma .Net, da Microsoft, acabaram de lançar a versão 2.0 do projeto.”

Enviado por Rafael Peregrino da Silva (rperegrinoΘlinuxmagazine·com·br) – referência (linuxmagazine.com.br).

“Depois de muito tempo no forno, finalmente foi lançado o mono 2.0. Apesar dos releases anteriores já suportarem quase que todo .NET 2.0, este entrega aquele pouco que faltava, como partes do winforms. Além do avanço no lado da API, o runtime está muito mais maduro quanto ao suporte a generics. O consumo de memória é muito menor e já é possivel usar compartilhamento de código entre várias instâncias de um mesmo tipo. O anúncio completo pode ser lido no blog do Miguel: http://tirania.org/blog/archive/2008/Oct-06.html”

Enviado por Rodrigo Kumpera (kumperaΘgmail·com) – referência (tirania.org).


• Publicado por Augusto Campos em 2008-10-07

Comentários dos leitores

Os comentários são responsabilidade de seus autores, e não são analisados ou aprovados pelo BR-Linux. Leia os Termos de uso do BR-Linux.

    Renato (usuário não registrado) em 7/10/2008 às 9:28 am

    Sem dúvidas, o Mono está múito maduro, precisa melhorar em vários pontos principalmente na questão da performance porém tem funcionalidades que estão presentes no MONO que nem o .Net tem. A comunidade do mono está de parabéns.

    Marcelo (usuário não registrado) em 7/10/2008 às 9:32 am

    Roda uma aplicação gráfica não-olá-mundo feita no Windows?

    Marcelo, clique no link que você verá uma imagem do paint dot net rodando 100% no mono.

    Acho muito interessante o trabalho dos caras, mas me assusto quando vejo um negócio com cara de Windows (o navegador web do mono, usa o gecko (engine dos produtos da mozilla) mas tem cara de internet explorer 6! Alguém me explica isto? hauahuah

    Ah, e o mono não é multiplataforma (linux, bsds, mac, windows, etc?) ???

    Rodrigo Kumpera (usuário não registrado) em 7/10/2008 às 10:14 am

    tenchi, o mono é multiplataforma sim, funciona tanto em linux, windows, osx, bsd e solaris.

    Bruno Fabricio (usuário não registrado) em 7/10/2008 às 10:57 am

    Eu fico muito feliz com o pessoal do projeto Mono.
    Estão fazendo um grande trabalho, mostrando que o potencial em desenvolvimento em SL não é só de Python, perl e outras linguagens maravilhosas.
    O Mono está ótimo, fico muito feliz com esses avanços.

    João Marcus (usuário não registrado) em 7/10/2008 às 12:56 pm

    O Paint.NET não é multiplataforma, não. A versão oficial é somente para Windows, pois há chamadas a DLLs do Windows dentro do software.
    Isso acontece com a maioria esmagadora dos projetos de software em .NET da Microsoft. Sinceramente, praticamente ninguém que desenvolve para .NET se importa com o Mono, uma vez que, quando você escolhe o .NET, escolhe automaticamente o Windows, e não se preocupa com outras plataformas. Eu mesmo desenvolvo para .NET, e estou pouco me lixando. Tudo o que eu faço é para Windows. Se quiser algo multi-plataforma, desenvolvo em Python, ou Java, ou algo assim.

    O Mono é um projeto legal, mas sempre dependerá do .NET da Microsoft, que é o padrão de fato (a tal padronização é feita totalmente pela Microsoft, não há envolvimento nenhum de ninguém de fora). O simples fato de que eles chegaram aonde estão é impressionante. A Microsoft não se importa com o Mono e só oferece ajuda quando serve aos próprios interesses. Não os culpo por isso. Afinal, se o pessoal do Mono quer fazer uma implementação do .NET, a Microsoft não tem nenhuma obrigação de ajudar.

    nemesis (usuário não registrado) em 7/10/2008 às 2:00 pm

    Eu sempre gostei de jogar ovos no projeto, mas tenho que dar meus parabéns dessa vez. É positivamente impressionante como o projeto amadureceu e se tornou tão completo e versátil em puro número de APIs suportadas e instaladas junto.

    Não gosto de C# (de java + delphi virou uma espécie de Python verboso), muito menos de VB. Mas boa parte do mundo, goste-se ou não, roda hoje nas VMs JVM e CLR (.NET). Muitos desenvolvedores hoje não aprendem mais C/C++, só Java ou C#. É preciso que esses imbec, digo, desenvolvedores possam desenvolver no Linux também. Dos males, o menor.

    As coisas que mais gostei de ver:

    * Mono 2.0 contains an API complete implementation of .Net’s System.Windows.Forms (winforms) namespace, allowing winforms applications to run on Linux, MacOX and other Unix systems. (eles conseguiram!)

    * C# 3.0 compiler implementation, with full support for LINQ.

    * Extensive support for databases: PostgreSQL, DB2, Oracle, Sybase, SQL server, SQLite and Firebird.

    * Mono’s SQLite support: a library to create and consume databases created with SQLite.

    * Mono.Posix: a library to access Linux and Unix specific functionality from your managed application. With both a low-level interface as well as higher level interfaces.

    Licenciamento para plataformas fechadas populares também é interessante:
    Licensing is available for statically linking Mono (for the Apple iPhone, Nintendo Wii platforms and other proprietary operating systems)

    Em minha opinião, uma opção muito melhor e mais completa para desenvolver aplicações .NET do que a própria oferta da Microsoft. É claro, isso tudo pouco importa se você eventualmente jogar a toalha e achar completamente essencial desenvolver com Visual Studio…

    Não acredito nessa estória de linguagem mutiplataforma. Elas não existem.

    Tudo começou com o C. A Borland criou um tal de Turbo C Compiler e quando você se empolgava com a conio.h e precisava portar sua aplicação via que tinha vendido a alma ao diabo.

    Depois o Java. Quando tudo parecia perfeito… Tudo por água abaixo.

    Delphi que gerou o Kylix …. esquece isso não existiu, foi apenas um devaneio.

    Agora o .Net é a “bola de neve” da vez e será sempre será assim. Um padrão é criado e alguém cria uma super biblioteca que facilita a vida de todo mundo, mas só se escreverem para a plataforma da tela azul.

    O Linux só vai crescer quando fizer igual ao Mac. Ignorar completamente o mundo Windows e caminhar por suas próprias pernas.

    Usando C e C++ é possível ter tanto ou mais portabilidade do que com essas linguagens ultramodernas.

    Um bom programa feito em .net multiplataforma.

    http://www.incollector.devnull.pl/

    nemesis (usuário não registrado) em 7/10/2008 às 4:46 pm

    welbravo:
    “Não acredito nessa estória de linguagem mutiplataforma. Elas não existem.”

    Duendes não existem. Python, Java, Ruby, Perl, Lisp e outras sempre foram multiplataforma. Ou atreladas a uma única, seja por necessidade da aplicação, seja por pura ignorância do desenvolvedor.

    “Tudo começou com o C. A Borland criou um tal de Turbo C Compiler e quando você se empolgava com a conio.h”

    Não culpe C pela Borland.

    “Depois o Java. Quando tudo parecia perfeito… Tudo por água abaixo.”

    O que veio por água abaixo foram aplicações Java de desenvolvedores idiotas específicas para a JVM aberração da Microsoft.

    “Delphi que gerou o Kylix …. esquece isso não existiu, foi apenas um devaneio.”

    GNU Pascal e Lazarus a cada dia melhor, por outro lado. O mesmo para FreeBasic.

    Acho que o que ele quis dizer é que é possível desenvolver multi-plataforma, mas quando surge uma opção mais produtiva que é amplamente adotada, ela consegue isso sendo dependente de uma plataforma. Foi assim com o conio.h e com diversas outras soluções.

    Programas multi-plataformas conseguem a independencia ao preço de não poder aproveitar todos os recursos próprios de um SO ou de suas APIs proprietárias. É um dos motivos de um modelo nunca matar o outro.

    cristo (usuário não registrado) em 8/10/2008 às 6:59 am

    @João Marcus

    Então para que serviu o contrato que a Novell fez com a Microsoft então, pois venho conferindo as noticias do openSuse News e sempre vejo Miguel dizendo vários progressos já obtidos na implamentação do Mono com base de muita da especificação do .Net da Microsoft, aquela especificação que a Microsoft disse que não iria apresentar.

    Uma coisa que tenho que admitir é que sempre gostei mais da idéia tecnológica do Mono desde o inicio, já que em muitos fatores supera a tecnologia Java, isso não tem haver com sou viciado em visual studio ou ser microsoftiano, já que nenhum destes dois grupos pertenso, mas em termos tecnológicos.

    Só para se ter uma idéia a tecnologia Mono (assim como .Net) possuem suporte a linkagem estática, coisa esta que faz muita falta na tecnologia Java (no caso adeus a classpath), suporte a internal method que diz que aquele método só pode ser usado apenas dentro daquele namespace, o fato do Mono particularmente ter bindings para tudo sendo o mesmo um framework único, no caso de desenvolvimento de jogos você tem bidings para OpenGL, SDL, OpenAL, entre outros no Tao Framework sem tanta preocupação com dependencias, a programação tanto no Java quanto na tecnologia Mono é bem mais simples, até para debuggar é um paraíso, coisa esta que C/C++ com todo o pesar (pois gosto muito destas duas linguagens) não tem, se fizer uma aplicação em Mono você tem a garantia que ela será multiplataforma, para isso é só não usar winforms, mas GTK-SHARP2 (que a programação também é bem mais agradável que em winforms), cada dia mais o Monodevelop esta mais maduro, a performance do Mono em si está impressionante, até mesmo o gerenciamento de memória da máquina virtual deixa você de queixo caido, só para ter uma idéia antes quando rodava uma aplicação Mono de cara o Mono ocupava de 100 a 300 mb (por causa das bibliotecas que carrega junto), agora ele só ocupa 4 a 30 mb dependendo a aplicação, no caso de 30 mb foi o Monodevelop.

    Nestes quesitos por isso digo que Mono é uma tecnologia promissora (mesmo eu sendo um desenvolvedor Java/C/C++), ainda mais promissora que .Net/Java, mas o que me fez deixar de continuar usando Mono na época foi a mudança radical que teve o projeto, pois antes no inicio o projeto tinha como objetivo seguir uma linha única independente do .Net da Microsoft (implementando apenas as bibliotecas ECMA por serem padrão e o resto só tecnologia própria do mono), mas por pressão dos próprios usuários que mesmo os desenvolvedores explicando que Mono é Mono, os benditos usuários queriam que o Mono tivesse todas as apis do .Net, até mesmo queriam um Visual Studio para o Mono, por esse motivo o mono mudou seu percurso para a perseguição do .Net, o que realmente deu uma parada monstruosa no Mono em si, mas depois do trato com a Novell e Microsoft o projeto voltou a ativa.

    Espero que pelo menos continue com o caminho de tecnologia única que o grupo de desenvolvedores sempre disseram.

    O meu maior sonho será quando portarem as especificações basicas da tecnologia Java para Mono ou mesmo com o percurso do projeto OpenJDK a máquina virtual Java possa se basear mais na máquina virtual do Mono que está muito melhor. Além de que o Eclipse pudesse ser compilado no Mono.

    cristo (usuário não registrado) em 8/10/2008 às 7:07 am

    @marcosalex

    Rapaz ai a culpa não é nem da linguagem nem da tecnologia, mas do desenvolvedor e da biblioteca utilizada, pois a tecnologia apesar de permitir ser multiplataforma, isso não quer dizer que ela tenha todos os recursos de cada plataforma, por essa razão são criados bindings de bibliotecas nativas para suprir essa ausencia e por essa razão a aplicação em si acaba ficando presa a plataforma em questão, neste caso para que se possa resolver este problema será necessário criar uma aplicação em camadas ou mesmo API em camadas, assim como GTK e Qt, que tem bindings de cada sistema, mas com a diferença que a camada utilizada pelos programas não é a camada de bindings mas uma camada mais alto nível (no caso de GTK é o GDK, que mesmo assim não é a camada de bindings).

    Neste caso para se utilizar realmente estes recursos de forma menos sofrida terá que ou usar metodologias ou recursos que geralmente não se muito em linguagem procedurais, como interfaces, encapsulamento e entre outros (que para serem desenvolvidos em tecnlogias proceduais demandam de muita experiencia).

Este post é antigo (2008-10-07) e foi arquivado. O envio de novos comentários a este post já expirou.