| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | Two (Pontos:3, Esclarecedor) |
| | Bem, a lista de features impõe respeito. Se ao menos deixassem de chamar a isso .NET e cortassem com as ideias de compatibilidade com o .NET da Microsoft... aí então poderiamos estar perante algo útil e não algo que só ajuda a Microsoft a reforçar a sua mão de ferro. (hmmm, onde é que eu já ouvi isto?)
A propósito do Cairo, pelo que estive a ver já há um backend OpenGL em movimento. Um dia destes, quando o GTK e o QT usarem o Cairo, o Linux ficará com uma espécie de Quartz Extreme. E ainda há quem ache que o Longhorn vai matar o Linux e que a comunidade está parada à espera do golpe fatal...
-- Carlos Rodrigues
|
| | | | | | Do que disseste só há uma coisa em que discordo: eu acho que devem continuar a manter ideias de compatibilidade naquilo que é compativel. Sendo o mono baseado num ECMA standard é natural que muitas features sejam compativeis.
Um exemplo de que eles não estão a perder tempo a implementar features windows-only é as próprias SWF (System.Windows.Forms) em que preferiram fazer um wrapper com o wine para as implementar. Porquê isso? Simples. Se queres competir com alguém (mais forte que tu) tens primeiro que competir no terreno dele; quem desenvolver aplicações .NET tem uma forma quase completa de fazer transição para Linux usando o mono sem ter de dar desculpas que terá de reescrever a aplicação. As SWF são apenas um "bonus" de marketing, não um objectivo em si...
Este comentário foi publicado ao abrigo de leis internacionais "How to handle a Troll". |
| | | | | Nota que as SWF vão estar só mais para compatibilidade. Não é aconselhável fazer uma aplicação que corra em todo o lado em .NET só com SWF. O aconselhável é usar SWF no Windows, e GTK# no resto. Pode parecer confuso ter de fazer duas UIs, mas não é tanto. No futuro, com o XAML, até poderemos ter isso de borla: um template que é passado para SWF ou GTK# consoante o SO onde corre. É que mesmo que as SWF corram sem problemas no Linux (o que eu acho difícil, não gosto da ideia do Wine...), salta logo o problema do touch and feel da aplicação. Um exemplo prático é o copy+paste. Um utilizador do Linux está habituado a sublinhar+copiar, botão do meio+paste. Se tem uma aplicação onde isso não acontece, parece algo estranho. Quanto à compatibilidade, há standards, e eles existem é para isso.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Quanto à compatibilidade, há standards, e eles existem é para isso.
"Standards" e "Microsoft" na mesma frase torna-a automaticamente num oxímoro.
-- Carlos Rodrigues
|
| | | | | Estás por dentro do mundo dos Webservices? Se estiveres talvez tenhas uma opinião diferente.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | | Nota que não tou a defender a MS. Simplesmente acho que se eles quiserem colocar extensões proprietárias ao .NET, que o façam... também o fizeram para o Java e não foi por isso que o Java não deu a volta por cima e não lhes deu uma tareia fenomenal com o J2EE. Agora, no standard não podem mexer.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Eles só não conseguiram impôr a sua versão de Java por duas razões:
- O Java compatível-Sun (Sun, IBM, etc) era dono e senhor do servidor e a versão da Microsoft era maioritariamente (unicamente?) cliente. Por essa altura as applets já estavam a fazer tijolo e as aplicações cliente ainda não tinham descolado.
- A Sun processou a Microsoft e ganhou.
Mais uma vez a falta de domínio no servidor foi a perdição da Microsoft. Valha-nos isso. É exactamente por esta razão que acho que a credibilidade dada pelos esforços de compatibilidade do Mono ao .NET da Microsoft são muitíssimo perigosos, pois o .NET é a chave que pode abrir o lado do servidor às hordes da Microsoft. E se a Microsoft conseguir este domínio a indústria está condenada à estagnação. Nesse dia todos aqueles que estão nesta área por gosto podem começar a pensar em dedicar-se à pesca, porque a monocultura e a estagnação são tudo menos interessantes.
PS: quero aqui dar ênfase à questão do gosto pela área das tecnologias, pois também é isso que é o combate à Microsoft, o combate pelo direito de todos aqueles que gostam disto a poderem usar o que quiserem, inovar e trabalhar com gosto, sem que se tornem em formigas operárias sob controlo de um BigBrother do software.
Isto também afecta os consumidores finais, mas estes são incapazes de compreender as suas implicações. Eles usam, nós lutamos do lado técnico da coisa.
-- Carlos Rodrigues
|
| | | | "... pois também é isso que é o combate à Microsoft, o combate pelo direito de todos aqueles que gostam disto a poderem usar o que quiserem, inovar e trabalhar com gosto ..."
Por amor de Deus ! Este é talvez o post mais demagogico que vi aqui nos ultimos tempos. São argumentos como este que tiram credibilidade a muitas pessoas por estes lados.
|
| | | | Ai é mentira?
Então explica-me lá como é que acedo ao conteúdo de um documento gravado em *.doc?
Com o OpenOffice.org basta descomprimir o ficheiro e ir ao ficheiro xml, onde o conteúdo aparece em plain text. E no Word, explicas-me sff?
É assim tão difícil compreender que a Microsoft tenta dominar tudo e todos? Literalmente?
Dominus vobiscum |
| | | | Quanto tempo queres que te dê até que a Microsoft começe a incompatibilizar-se com os resto da indústria nessa área? É só o .NET começar a empurrar o Java para fora dos servidores (o que espero que não aconteça).
Neste momento o Java domina no servidor e o .NET pretende essa área também. A forma mais directa de o conseguir é adoptando os WebServices e facilitando o seu uso do lado do cliente. Actualmente a ideia geral é de que é mais fácil usar WebServices em .NET do que em Java, isto por causa do Visual Studio e não por alguma virtude da plataforma(*). Isto pode não ser bem verdade, já que eu não sei em que estado estão os IDEs para Java nesta área. O que acontece é que isto cria mindshare para o lado do .NET e pode levar muita gente a pensar que também é apropriado para o lado do servidor. Uma vez isto acontecendo o punho de ferro da Microsoft está consolidado e passam à fase do extend. Esta táctica já foi usada inúmeras vezes e nada indica que desta vez seja diferente.
(*) Eu já fiz algumas coisas com WebServices em Java (Tomcat + AXIS) e não achei nada de complicado desde que nos mantenhamos dentro da área para a qual os WebServices foram concebidos, serviços simples. Só se tornou complicado porque o que eu pretendia fazer já saía do escopo de aplicação dos WebServices e entrava mais na área do RMI ou do CORBA (migração de código e passagem de tipos complexos), o que implicava malabarismos e nestes casos a simplificação do Visual Studio não ajudaria em nada, é sempre preciso ir lá abaixo bater no metal. Sendo assim não me parece que a vantagem do .NET seja assim tão grande.
-- Carlos Rodrigues
|
| | | | | Nota que o mundo dos WebServices é composto por standards. Nesse mundo andam empresas como a Microsoft e a IBM, lado a lado a definir os standards. Eu no outro dia fui a um evento da Microsoft e só ouvia falar em standard's e interoperabilidade por todos os lados. Tens aqui um resumo no meu blog. Um dos oradores da Microsoft disse algo que achei engraçado, ele disse que a Microsoft levou uma tareia descomunal do Java pelo política do "Build once, run anywhere". Se as empresas querem standards, se querem independência da plataforma, então a Microsoft tem de caminhar para esse fim para não ficar mais para trás a nível empresarial. Pode-se fazer um WebService em qualquer lado, mas as empresas provavelmente vão procurar a maneira mais fácil de o fazer. Acho que vão ficar presas mais facilmente a uma API do que à linguagem/plataforma. Eu nunca fiz WebServices em Java, mas neste momento fazê-los em .NET também é muito simples. Mas é como tu dizes, é para fazer coisas simples... Com o Indigo a Microsoft dá a possibilidade de fazer coisas muito a sério, muito facilitadas. Se eu faço WebServices e tenho o Indigo que é excelente, acho que fico mais facilmente preso a ele por isso, do que por ser em .NET. Mais importante do que é melhor, se é Java ou .NET, é saber em qual tenho acesso a melhores ferramentas.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Eu já ouvi muita conversa sobre standards saída da Microsoft, normalmente esses standards incluem o .doc e o ActiveX... Também já ouvi muita conversa de interoperabilidade e ambientes heterogéneos, normalmente acerca de diferentes versões do Word e do Windows.
-- Carlos Rodrigues
|
| | | | Sendo o mono baseado num ECMA standard é natural que muitas features sejam compativeis.
Alem do CLI/C#, nem tudo foi lancado sobre o ECMA, mais uma vez a comunidade oss a ficar refem de tecnologias proprietarias. Samba/wines rings a bell? BAstara a' m$ trocar uma ou outra implementacao, meter mais um ou outro argumento nesta e naquela funcao pra tornar todo este "dream" de compatibilidade num verdadeiro pesadelo. E ainda ha aqui a questao das patentes.
During the past two years alone, according to the U.S. Patent and Trademark Office's online search server, Microsoft has received about 1,000 patents, or an average of 10 a week.
Nao acredito que a m$ permitira que o mono se torne relevante nas plataformas windows em detrimento do .NET. A nao ser que o Icaza tenha algum secret agreement com o Bill Gates de nao agressao mutua.
Mas sabendo que quem suporta o Gnome, agora e' a Novell, Novell->Netware->Microsoft nao me cheira que possa existir um acordo tao claro.
Acho que a m$ esta e' a ser permissiva ao ponto de deixar criar uma user base, e que a tecnologia .NET/C# seja jargao currente na comunidade. Para mais tarde controlar a seu belo prazer.
Sempre fui algo ceptico quanto a esta plataforma, mas se o que prometem torna-se realidade, acho que o mono tem pernas pra andar.
Enquanto as SWF (System.Windows.Forms) nao estiverem totalmente implementadas w/ ou w/o wine (sera que vai estar 100% alguma vez?) a aposta podera ser na utilizacao dos bindings C# pra GTK+, GTK#
Considero mesmo que o mono podera tornar-se uma alternativa "multiplataforma" ao JAVA/SWING e posteriormente .NET/Avalon/XAML mesmo para quem so desenvolve em windows, mas em ambos os casos, a acontecer, acredito que so com a colaboracao do Mozilla/XUL
Estamos no limbo, tudo depende.
make world && !war; |
| | | | Um exemplo de que eles não estão a perder tempo a implementar features windows-only é as próprias SWF (System.Windows.Forms) em que preferiram fazer um wrapper com o wine para as implementar. Porquê isso? Simples. Se queres competir com alguém (mais forte que tu) tens primeiro que competir no terreno dele; quem desenvolver aplicações .NET tem uma forma quase completa de fazer transição para Linux usando o mono sem ter de dar desculpas que terá de reescrever a aplicação.
E é nisto que o Mono é altamente pernicioso, e é por isto que falava que deviam largar por completo a ideia de compatibilidade com o .NET da Microsoft e apostar no Mono como uma plataforma por si mesma. O Mono não pode competir com o .NET, não pode porque não consegue, a Microsoft estará sempre um passo à frente e a compatibilidade será sempre uma ilusão, e não pode porque não deve, pois dá a desculpa necessária para se escolher .NET, a desculpa da portabilidade. Como isto não passará de uma desculpa, o .NET toma como refém mais uma vítima. O .NET é o instrumento mais poderoso de lock-in da Microsoft, e dar-lhe munições como as aspirações de compatibilidade do Mono é a razão pela qual eu discordo da existência deste projecto (poderia mudar de ideias se a situação mudasse, tal como eu dizia no post anterior).
-- Carlos Rodrigues
|
| | | | Já algum tempo que percebi esse teu ponto de vista, com o qual concordo, como é possivel perceber do que eu escrevi.
Mas vou-me explicar melhor. Eu como programador uso o mono devido às suas caracteristicas técnicas; devido à possibilidade que o mono me dá de criar aplicações que correm em multi-plataforma e também porque me permite empregar conhecimentos que eu já adquiri -- aqui gosto de salientar que o C# foi concebido pela mesma pessoa que concebeu o Delphi, com o qual tive a alegria de trabalhar durante anos.
Naturalmente que no mono uso GTK# para os interfaces e tento seguir todas as recomendações que são sugeridas para produzir aplicações portáveis, de modo a tornar a aplicação o mais estanque possivel e menos susceptivel a quebrar com alterações externas.
Eu apenas uso o argumento da compatibilidade numa situação muito particular: que é como chamariz para quem desenvolve em .NET poder desenvolver em mono, ou para pelo menos lhe chamar a atenção para ver quais aos coisas que o mono tem que o .NET não tem. Aqui espero também contribuir para um desenvolvimento superior do mono com inclusão de features que não estejam presentes no .NET, e que sejam realmente uteis.
O engraçado deste "argumento" é que é uma faca de dois gumes, pois permite à MS fazer exactamente o mesmo, como tu muito bem referiste. Pessoalmente acho que o "MS stack" no mono é importante para pelo menos dar a possibilidade dessa compatibilidade, mas nunca (tal como acontece) esse stack deve ter prioridade sobre os outros.
Agora só num futuro saberemos qual o resultado...
Este comentário foi publicado ao abrigo de leis internacionais "How to handle a Troll". |
| | | | Support for Linux, MacOS X, Windows, Solaris and HP-UX operating systems. (exclusivo)
o suporte para Macos X, unix et all deixa muito a desejar
por exemplo mono em free/netbsd e' uma mentira alem de nem todas as classes/bindings estarem implementadas, e sem pacotes pra macosx e' uma PITA pra o compilar, qt mais pra o por a correr
make world && !war; |
| | | | | | Pois, realmente ainda não há muito suporte para plataformas não-Linux. Seja como for, não sei se já viste, mas aqui está uma imagem do MonoDevelop a correr no MacOX. Se uma aplicação como o MD corre, é sinal que as coisas tão a andar bem! ;)
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Fala-se muito sobre a diferença entre standards abertos e standards proprietários.
Nesta thread, o racme realçou o facto de o C# e o CLI serem normas ECMA enquanto a API do .NET não e a possibilidade da MS mudar a API do .NET.
Contudo, o que é que impede a MS de no futuro implementar extensões não-ECMA na sua implementação de C# e CLI? Já o fez com Java e HTML por exemplo.
Por outro lado, o formato PDF e OpenOffice.org também são especificações proprietárias (da Adobe e da Sun respectivamente), não são da responsabilidade de nenhuma organização independente. À excepção da atitude das empresas em questão, qual é a diferença entre isto e o .NET?
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | | Por outro lado, o formato PDF e OpenOffice.org também são especificações proprietárias (da Adobe e da Sun respectivamente), não são da responsabilidade de nenhuma organização independente. À excepção da atitude das empresas em questão, qual é a diferença entre isto e o .NET?
No caso do PDF, não há diferença, a Adobe poderia sempre introduzir extensões incompatíveis mas qual seria o objectivo disso? Eles próprios promovem o PDF como um standard interoperável completamente especificado. No caso da Microsoft não, o .NET é deles e desenganem-se aqueles que pensam que a Microsoft deseja mais portabilidade/interoperabilidade do que as suas próprias implementações, quer em Windows, quer nos Smartphones. A Microsoft propôs parte do .NET como standard só para atirar areia aos olhos dos "consumidores" e dar uma falsa ideia de standardização.
O formato do OpenOffice.org é completamente diferente, não é um standard proprietário. O OpenOffice é opensource, qualquer extensão ao formato estaria à vista de todos. Mesmo que eles não estivessem a propor o formato OpenOffice como um standard de interoperabilidade completamente específicado, existiria sempre a específicação mais detalhada, que é o próprio código.
-- Carlos Rodrigues
|
| | | | Eu estava a referir-me ao facto de haver uma especificação para o formato OpenOffice.org/StarOffice (sendo que o OpenOffice.org é apenas uma implementação livre dessa especificação, tal como o xpfd é uma implementação livre do PDF).
Embora o desenvolvimento do formato pareça aberto, o copyright do documento dá-me a impressão que a Sun têm a última palavra sobre o assunto.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | O StarOffice é apenas uma versão do OpenOffice com ícones diferentes e uns extras proprietários, portanto é no OpenOffice que se define o formato. Como o OpenOffice é opensource (embora a maioria do desenvolvimento seja feito na Sun) não estou a ver onde está o problema.
-- Carlos Rodrigues
|
| | | | Se a SUN quiser pode criar extensões proprietárias ao formato dos documentos do OpenOffice.org para tentar arrastar mais pessoal para o SOffice que para o OOo.
Aí poderia haver um problema no momento em que uma pessoa enviasse documentos c/ extensões proprietárias para alguém que só tem o OOo. No entanto, bastava um tipo com um bocado mais de tempo para descomprimir o documento e tentar perceber o que tinha sido alterado para se poder criar um filtro novo.
---
Este espaço pode ser seu! |
| | | | Só que a Sun não faria isso por duas razões. Em primeiro lugar porque o OpenOffice é muito mais popular que o StarOffice, logo é do interesse deles manter o formato igual ao da versão maioritária, e em segundo lugar porque o formato aberto e interoperável é um dos seus chavões de marketing, como quem foi ao java-on-demand pôde comprovar.
-- Carlos Rodrigues
|
| | | | Não me dizes nada de novo, mais ainda porque como disseste e bem o SOffice é o OOo c/ mais uns pozinhos de perlim pimpim em cima. Além de que, se não estou em erro, o formato dos documentos do OOo são baseados nos standards do OASIS.
---
Este espaço pode ser seu! |
| | | | Que sofrem de patentes de software, algumas delas da própria Sun... Microsoft, IBM, etc...
A única solução é não haver patentes de software e deixar a malta competir lealmente, como até agora tem sido.
|
| | | | A Sun nunca faria nada de mau... A Microsoft só poderá fazer coisas más. É esta a tua conversa, nao passa disto. Será que também conseguiste prever o momento em que a Sun tirou o Java de um comité de standarts para fazer o que lhes desse na telha?
|
| | | | A Sun tem tanto potencial para fazer algo mau como a Microsoft. Aqui o que interessa é que o "mau" também seria mau para eles. Além do mais o OpenOffice não é o único projecto opensource controlado por uma empresa, e não é o único que tem uma versão comercial com uns extras. Basta lembrarmo-nos do Mozilla até há bem pouco tempo, o Evolution, o QT...
-- Carlos Rodrigues
|
| | | | Não te esqueças do MySQL...
---
Este espaço pode ser seu! |
| | | | Basta ir a http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office para se ver que o formato do OpenOffice está em vias de ser estandardizado. Basta ir a http://xml.openoffice.org/ para saber todas as informações sobre o formato. Basta ser preguiçoso para não se investigar isto antes de se fazerem afirmações erradas.
|
| | | | Eu li isso antes de escrever o comentário..
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | Faço a pergunta, será o Mono uma aposta aceitácel para os que vão desenvolver em Linux? Como sabemos, o desenvolvimento em Linux é primordialmente realizado em C, seguido de C++ e linguagens de scripting. Fora azureus e eclipse, qual é o programa de grande circulação em Java que destronou alternativas nativas em Linux? Existe no fundo uma barreira entre os programadores contra as máquinas virtuais, nomeadamente Java, e não prevemos, sinceramente, que isso se venha a alterar em breve. Não penso que os problemas de outrora em Java (performance e interfaces gráficas) ainda sejam um obstáculo. Se por um lado, as máquinas se tornaram mais rápidas, também a linguagem se socorre de outras ferramentas (swt, hotspot) para se certificar que já não é a lentidão dos tempos em que eu a programava. Resta o problema da memória. Uma extensão proposta na JCP (não, não é aquela JCP, Odete!) prevê a partilha de memória de código nas máquinas virtuais, como se faz aliás em qualquer sistema operativo corrente. No entanto, o Java não teve grande aceitação, salvo no servidor ou na comunidade académica e científica. Porque iria o Mono ter? Não é nenhuma crítica, como devem saber, é uma pergunta sincera que, diga-se, gostaria muito de ver discutida aqui. Francisco Colaço
Em Portugal nada se conclui acerca da existência de vida inteligente no Planeta Terra. |
| | | | | | É uma boa questão para a qual, segundo a minha convicção pessoal, existe uma resposta simples: O Java não vem por omissão nas distribuições por não ser suficientemente aberto (ver este artigo).
Actualmente não há propriamente nada a apontar ao Java do ponto de vista técnico e de performance, isto é, muitos projectos recusam Java mas usam Python, que tem uma performance inferior. A razão é simples, o Python vem com qualquer distribuição e o Java não.
O Mono é opensource e isso dá-lhe uma vantagem sobre o Java. Mas nada faz prever que venha a ser incluído em alguma distribuição, a não ser que algo importante dependa dele e, pelo menos pela parte do GNOME, nada se observa no horizonte.
Posto isto, o Mono deverá cair mais do lado do servidor, onde vai competir com o Java (luta complicada). Aqui a ubiquidade não se coloca, já que quem desenvolve para servidor sabe que não custa nada instalar uma JVM a quem já vai ter de configurar um servidor. É este o fosso que separa o mercado servidor do mercado desktop.
Fugindo do tópico, numa altura em que a Microsoft inclui o .NET no Windows só seria vantajoso para a Sun fazer as alterações necessárias para que o Java se tornasse ubíquo no Linux, fomentando a criação de aplicações interessantes (business-oriented ou não) que, correndo também em Windows, seriam um incentivo ao Java também nesta plataforma. Mas a Sun tem vistas curtas e não compreende que o desktop generalizado pode ser encarado como um trampolim e não apenas como algo que ou se quer dominar ou não se entra...
-- Carlos Rodrigues
|
| | | | | Java pode não ser muito utilizado naquelas aplicações que o "joe user" costuma encontrar no Tucows ou nas distribuições Linux, mas tem grande penetração em aplicações de âmbito empresarial, em software científico, e em jogos (sim, há toneladas de jogos em Java para telemóveis e disponíveis na Web). É verdade que podia ser mais utilizado se a Sun se tivesse preocupado, desde cedo, em dar-lhe um GUI bonito e tivesse apostado na rapidez.
Actualmente o Java já consegue ter um GUI bonito e ser rápido, mas já criou anticorpos em muitos developers. Para agravar, a moda .NET que invade as universidades está a provocar danos graves à expansão da linguagem. E como se isto tudo não bastasse, ainda há o Mono que veio alimentar ilusões de compatibilidade em alguns...
|
| | | | E como se isto tudo não bastasse, ainda há o Mono que veio alimentar ilusões de compatibilidade em alguns... Epah já cansa essa lengalenga. Em que te baseias para dizer que não há compatibilidade? Dá-me argumentos.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Não precisa, eles são evidentes. O Mono baseia-se no standard ECMA e a Microsoft já vai bem à frente disso.
-- Carlos Rodrigues
|
| | | | Engraçado como pessoas que não usam, que não conhecem, se põem com palpites desses.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | E é engraçado como pessoas que estão enfeitiçadas pela Microsoft são incapazes de ver a realidade.
-- Carlos Rodrigues
|
| | | | Claro, só tu é que vês a realidade. Já me tinha esquecido disso.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Sinceramente, se não concordas comigo porque não voltas lá para o teu .NET? Afinal de contas tu estás do lado do mais forte portanto não precisas de ter preocupar...
-- Carlos Rodrigues
|
| | | | Realmente, isto parece uma conversa de "meninas da rua" (vulgarmente denomindas de P****S).
Na realidade nenhum de vós é possuidor da razão, na realidade nenhum de nós a detém.
No meio disto tudo, à muitos pontos que devem ser realçados:
- O JAVA, devido á sua licença e à forma com a SUN tem lidado com novas releases. Li nesta tread que a SUN demorou a melhorar o seu GUI designer que obviamente criou "anti-corpos" em muitos programadores para voltarem a tentar usar. Em relação à licença, o JAVA (infelizmente) não vem instalado por defeito nas disversas distribuiçoes Linux precisamente por não ser GPL.
- O Mono, possui uma licença que deveria ser agradável aos olhos da comunidade OpenSource, já que é GPL. Podemos ler no site do Projecto Mono
"What license or licenses are you using for the Mono Project?
The C# Compiler is released under the terms of the GNU GPL. The runtime libraries are under the GNU Library GPL. And the class libraries are released under the terms of the MIT X11 license.
The Mono runtime and the Mono C# Compiler are also available under a proprietary license for those who can not use the LGPL and the GPL in their code."
Só pela licença, o Mono deveria ser a ferramenta escolhida pela comunidade, mas não, devido a ser uma implementação de uma framework desenvolvida inicialmente pela Micro$oft, o projecto Mono já é mau.
O pior de tudo é que as pessoas, mesmo antes de experimentarem, ou verem como é, já dizem que é mau. Experimentem e depois digam qualquer coisa.
Outro ponto que gostaria de referir é, o Window$ foi inicialmente desenvolvido em C/C++ e Assembly, e mais tarde a linguagem que mais desenvolver para Window$ foi o Visual Basic.
Isto serve para respoder ao problema que em linux até hoje foi usado essencialmente C/C++ e linguagens do tipo script (Perl, PHP, Python, bash script, etc). Linguagens onde era dificil desenvolver interfaces gráficos. Se calhar está na altura de fazer aqui um "fork" entre as linguagens dos Sistema Operativo, e a linguagens de desenvolvimento para EndUser, onde realmente o bonito importa, tanto como a funcionalidade.
Outra coisa é a compatibildiade. Infelizmente a Micro$oft não faz nada que seja realmente compativel, a não ser com aplicativos próprios, mas, isso não quer dizer que tenhamos que ser iguais a eles. Porque é que não podemos desenvolver algo que possa realmente ser compativel com o que já existe !!!?!??! Somente porque o que existe é Micro$oft???
(())
Esqueleto
|
| | | | Sinceramente... se eu fosse outro se calhar desistia... não há dúvidas de que a Microsoft tem lá mentes poderosas. O .NET é realmente mais potente do que LSD...
-- Carlos Rodrigues
|
| | | | Já escrevi sobre o assunto numa mensagem intitulada "Devemos desconfiar do .NET" e que tu leste, e à qual tu respondeste escrevendo: Concordo completamente contigo. Se entretanto mudaste de ideias então rebate com argumentos, tal como eu fiz...
|
| | | | | Desculpa, mas nesse post falavas de coisas epsecíficas como o P/Invoce e as SWF, e do perigo de estar "dependente" da Microsoft. Não há milagres. Fora isso, há assim tanta incompatibilidade? Com que experiência dizes isso? Sobre o que tu escreveste eu não mudei de ideias. Sobre o facto de o Mono só ter compatibilidade em ilusões de alguns, não concordo. Eu tou a fazer uma aplicação web que já tem um tamanho considerável e corre sem tirar nem por no Windows e no Mono. Sem qualquer problema. Tanto que eu desenvolvo em Linux e o meu colega em Windows e não tivemos 1 problema sequer. Quanto às SWF, concordo que não se deve aceitar a compatibilidade como certo... mas como disse num post acima, será má política apostar nas SWF para aplicações multiplataforma. O .NET/Mono não são só as SWF... são MUITO mais que isso. Julgar toda a framework com base nas SWF é errado.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Desculpa, mas nesse post falavas de coisas epsecíficas como o P/Invoce e as SWF, e do perigo de estar "dependente" da Microsoft.
Como eu já disse uma vez em resposta a um comentário teu... Só é compatível naquilo que não é incompatível.
-- Carlos Rodrigues
|
| | | | Faço a pergunta, será o Mono uma aposta aceitácel para os que vão desenvolver em Linux? Como sabemos, o desenvolvimento em Linux é primordialmente realizado em C, seguido de C++ e linguagens de scripting. E isso já não cansa? O desenvolvimento em C/C++ para Linux é algo que pode ser uma autêntica dor de cabeça, isto é algo que eu não compreendo. Porque é que cada distro tem de ter as suas regras? Porque é que há RPMs específicos para distros e não genéricos? Porque é que se tem sempre tantos problemas com dependências? Não dá a sensação que se está a complicar de mais? A mim dá. Naturalmente que para quem já está habituado a desenvolver para Linux tudo isto é natural. Autotools/Automake, pkg-config, ldconfig, etc e tal são as coisas mais banais do mundo. Mas e se alguém não habituado a esta realidade quer desenvolver para Linux? Se eu quero fazer uma aplicação Rich Client, tenho de me estar a preocupar com N factores alheios. Bolas, eu só quero fazer uma aplicação, mas tenho de aprender X ferramentas novas. E depois ainda tenho de fazer RPMs para todas as distros que existem no mundo e arredores. Ah! E são ferramentas de build que só funcionam (com sorte) em nixes! Em Win não... porque os makefiles não são portáveis, só talvez com o cygwin para os mais corajosos. Não será melhor outra opção? Ainda eu não conhecia o .NET já achava o Java uma alternativa mais viável, ou até mesmo o Python. Acho que tudo tem o seu lugar, nada vai tirar o lugar ao C/C++, mas talvez haja espaço para outras tecnologias quando queremos Rich Client. Faço a pergunta, será o Mono uma aposta aceitácel para os que vão desenvolver em Linux? Como sabemos, o desenvolvimento em Linux é primordialmente realizado em C, seguido de C++ e linguagens de scripting. É uma boa pergunta, mas só o futuro o dirá. O Mono trará sempre consigo o Síndrome da Microsoft. Muitos utilizadores de Linux nem querem ouvir falar dele por ser uma tecnologia da Microsoft. Esquecem-se que usam abundatemente outras tecnologias que nasceram de meios proprietários (por exemplo, o Schema foi um standard sugerido pela Microsoft). Por outro lado o Mono pode trazer alguma malta do Windows para outros mundos. Eu acho que se o Java não teve tanta saída foi pela lentidão da UI(Swing) que lhe está associada... Essa lentidão não existe no Mono, porque vai directo sobre o GTK.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | | Welcome to the wonderful world of linux...
Be different, think for yourself. |
| | | | Mas e se alguém não habituado a esta realidade quer desenvolver para Linux? Se eu quero fazer uma aplicação Rich Client, tenho de me estar a preocupar com N factores alheios. Bolas, eu só quero fazer uma aplicação, mas tenho de aprender X ferramentas novas. E depois ainda tenho de fazer RPMs para todas as distros que existem no mundo e arredores. Ah! E são ferramentas de build que só funcionam (com sorte) em nixes! Em Win não... porque os makefiles não são portáveis, só talvez com o cygwin para os mais corajosos.
Digo-te o mesmo que costumo dizer a quem afirma que um monte de coisas de Linux não funcionam em Windows: mas o MSI Installer funciona em Linux nativamente?
---
Este espaço pode ser seu! |
| | | | Digo-te o mesmo que costumo dizer a quem afirma que um monte de coisas de Linux não funcionam em Windows: mas o MSI Installer funciona em Linux nativamente? Não percebeste onde quis chegar. Eu afirmei que montes de coisas de Linux não funcionam em Windows? Não, o meu post nem tem nada a ver com o win. O problema não compatibilidade LinuxWin, mas sim DistroXDistroY a nível de desenvolvimento.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | | Também o SWT vai directo (quase) sobre o GTK+, e nem por isso se encontram muitas aplicações para o utilizador final nessas tecnologias. Não me levem a mal: desconfio do Mono essencialmente por me parecer que vai desculpar muitos a desenvolver para .NOT julgando que desenvolvem para Linux e Mac e SGI, etc. E um momento depois... eis que a aplicação afinal não corre. Agora, como plataforma de desenvolvimento per se, será o Mono uma boa alternativa à compilação nativa ou às linguagens de scipting? Vamos pensar nisto como um exercício: Windows não é para aqui chamado. Existem várias alternativas para se programar aplicações de uso geral: C/C++ & associados; perl, tcl, python e scripting; java; mono saltam-me à mente. Python + C parece-me uma combinação poderosa, especialmente com o ctypes ou o pyrex. Será o Mono uma tão boa plataforma neste caso? O que trás para além do Java? Que vantagens tem em relação ao Python + C por perl + C ou C++? Sei que isso é polémico, mas podemos discutir isto fingindo que a MS não é para aqui chamada? Francisco Colaço
Em Portugal nada se conclui acerca da existência de vida inteligente no Planeta Terra. |
| | | | O que é que se passa com a página principal? Estão fartos de aparecer novos posts tanto neste como no artigo anterior e a página principal continua a indicar 15 comentários. O processo que faz a actualização crashou ou quê?
-- Carlos Rodrigues
|
| |
|
