| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Mais info aqui.
--
antonio soares |
| | | | > Qual será a ideia da Novell em apostar nestas migrações para Windows?
Que tal "aumentar a visibilidade dos produtos", "aumentar a base de utilizadores desses produtos" e "reduzir a dificuldade de migracao de sistemas Windows para sistemas GNU/Linux"?
|
| | | | Toda a estratégia da Novell parece ser óbvia. Tanto a estratégia da Novell com a da IBM são de integração dos seus serviços em sistemas heterogéneos.
Qualquer dia poderemos ser produtivos independentemente dos Sistema Operativo que usamos.
Hoje em dia, por exemplo, não posso chegar à empresa onde trabalho e dizer que vou começar a desenvolver em Mono + Linux, porquê? A resposta é bem simples;
* Primeiro, não tenho possibilidade de usar os sistemas de GroupWere da Micro$oft (Exchange Server), ou as soluções que existem ainda são experimentais.
* Segundo, o Mono ainda não é uma solução de desenvolvimento, aceitável quando comparado com a plataforma .NET. É verdade que praticamente tudo está portado, mas, ainda à lacunas, especialmente no SOAP.
* Terceiro, o MonoDevelop ainda não é um aplicativo finalizado o que leva a uma grande falta de produtividade. Claro que esta comparação é feita em relação ao IDE do .NET.
* Quarto, ainda não à "port" do Source Save para linux. Sim eu sei que o CVS é bem melhor, mas, a integração do SS nos projectos .NET é fantastica apesar de não termos diversas funcionalidades como várias pessoas poderem alterar o mesmo ficheiro.
* Quinto, não existem aplicações de modelização capazes de ajudar os programadores. É verdade que temos o DIA, mas, convenhamos que o M$Visio está muito mais à frente deste aplicativo.
* E todas as aplicações de gestão que posso comprar no supermecado ainda não correm em Linux. Apesar de já haver empresas que desenvolvem produtos exclusivamente para Linux, devido à procura ainda ser pouca, o desenvolvimento ainda é limitado.
Com esta estratégia da Novell, em portar a plataforma .NET para Linux, temos a possibilidade, dentro em breve, poder desenvolver no Window$ um aplicativo e poder realmente correr em quase todas as plataformas (SUN, HP, Linux, Max e Window$).
Claro que também temos o Java que já faz isto à muitos anos, mas, o facto de a plataforma .NET ser aberta, faz com que a sua evolução nos ultimos 2 anos tenham sido muito maior que a evolução do Java, comparativamente.
Não creio que de futuro a Micro$oft venha a fechar o standard C#, pois, ela só tem a ganhar com a universalidade desta linguagem.
Em relação à Novell, parece-me óbvio que com esta exposição no que diz respeito ao desenvolvimento e port de aplicativos do Linux para o Window$, está a educar os utilizadores para solução OpenSource, assim irá ser mais simples mais tarde mudar o sistema operativo e os utilizadores terem na mesma as suas aplicações sem diferenças.
É controvesso??? Com certeza que sim e tenho a certeza que esta será a melhor estratégia para que mais pessoas mudem de Sistema Operativo, deixando de vez de usar sistemas que não nos dão segurança nem fiabilidade que só usam porque tem mais escolha, para usar outros mais seguros e fiáveis usando a mesma escolha de software.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | | | Em termos de modelamento, parece-me que o Visio deixa bastante a desejar (o mesmo já não digo em termos de desenho de rede). De qualquer das formas para Linux, para além do DIA tens outras soluções como o umbrello, o kivio (q tenta ser um clone do Visio, mas ainda está a muitos anos luz), e o ArgoUML (e o seu parente rico, o Poseidon). Além disso, para quem quer investir sempre tens a ferramenta de modelamento por excelencia, o Rational Rose.
--
What, Me Worry? |
| | | | Sinceramente, eu uso o DIA para todo o tipo de diagramas, à excepção para modelação de software (diagramas de casos de uso e coisas dessas), mas num ambiente Windoze também não usaria o Visio para isso, mas sim um Rational Rose...
Para todos os outros tipos de diagramas, actualmente (quando comecei a usar o DIA nem por isso) o DIA está (a meu ver) muito mais simples, intuitivo e user-friendly que o o M$ Visio.
|
| | | | Para todos os outros tipos de diagramas, actualmente (quando comecei a usar o DIA nem por isso) o DIA está (a meu ver) muito mais simples, intuitivo e user-friendly que o o M$ Visio.
Quando tiveres um modelo ER a sério ou quiseres fazer um modelo de rede a sério mesmo, vem-me dizer que o DIA é melhor....
Só se mudou muito nos últimos meses....
Há muitas ferramentas open-source/free software que evoluiram muito ultimamente.... mas este tipo de aplicações não é exemplo, nem de longe nem de perto!
Yours, McB!
They told me it need Windows 95 or better, so I chose Linux |
| | | | 1) Evolution e Kontact fazem isso;
2) Nem comento... ou melhor, ao estilo do Leitão: "o .Net ainda não está Enterprise Ready". Vocês é que julgam que sim...
3) Quando a bailarina não sabe dançar, diz que o chão está torto. Ainda me lembro dos tempos em que se faziam websites dinâmicos com nada mais que o notepad (não era Panzer? :) )
4) Mais uma vez: estás a gozar?! O VSS deve ser a maior bosta que por aí anda! Pelo menos, vira-te para o Subversion que tem integração com o IDE...
dass, vocês e a merda da integração com o IDE: abram os olhos!!!!
5) Nas palavras da Virgem Maria: "come again?" (ripado de outro lado): http://borland.com/together/
Só não é de borla, mas já que pagam o Visio também podem pagar omqq.
6) pois, é o problema do costume...
Portanto, a razão porque não se muda de plataforma é porque a troca de IDE vai levar à perda de produtividade. Right... o IDE é uma peça fundamental.
---
Este espaço pode ser seu... |
| | | | > O .Net ainda não está Enterprise Ready. Vocês é que julgam que sim...
Tendo em conta o .NET, em certas areas, passou a perna ao J2EE, alguem deve andar distraido !!??
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | a sério?? e que áreas são essas?
---
Este espaço pode ser seu... |
| | | | Infelizmente quem toma as decisões não são os programadores, mas, as chefias e no meu caso específico, a empresa tomou estas decisões.
Tenho pena que não tenhas entendido isso, mas, isso deixo para outras conversas.
A minha opinião fica. Quando alguns destas soluções no mundo OpenSource estiver ao nível das que já existe no Window$, penso, que não haverá mais motivos para desculpas e as empresas irão mudar a sua forma de pensar.
Neste momento, as empresas, ainda estão muita agarradas ao facto de pensarem que a Micro$oft lhes dá suporte real e não conseguem ver se tiverem um ecrã azul, não é a Micro$of que lhes vai recuperar os dados, mas, empresas de manutenção que são contratadas a peso de ouro para fazer esse trabalho e se esquecem é que no mundo OpenSource é precisamente isto que é oferecido, desta feita de uma forma clara.
Eles usam o Window$ a seu próprio risco.
Não estou contra nada, muito menos contra o OpenSouce como as tuas palavras parecem evidênciar, mas, sou a favor da evolução e da interligação de plataformas heterogéneas e penso que, apesar de recente, a contribuição da Novell no desenvolvimento da FrameWork .NET para Linux é importante para essa interligação.
Ainda estou à espera do dia de poder chegar aqui na empresa e poder colocar um Linux e ser tão produtivo quanto os meus colegas, ou como sou com o .NET, iterligar-me com o sistema de gestão de versões adoptado pela empresa, usar a FrameWork de trabalho escolhida pela empresa, aceder ao Exchange, imprimir modelos de dados e de rede com qualidade, etc.
Infelizmente ainda não posso fazer isso, mas, penso que usando a mesma Framework de base aceite pelo Window$, esse problema deixará de ser um problema, para ser uma solução.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | É tudo uma questão de perspectivas: quem me dera, um dia quem sabe, chegar a uma linux-shop com um windows e integrar automáticamente na autenticação LDAP, nos shares NFS, poder usar o GNU Arch... oh well :)
A .Net framework está a ser empurrada pela goela do programador abaixo e o Mono dá o último biqueiro quando se afirma como a solução para código multi-plataforma. O PRE falou, e muito bem, sobre os problemas entre um binário compilado em .Net a correr no Mono. Ora, eu já experimentei correr código compilado com o JDK da Sun numa JVM da Bea (o jRockit que li no blog do Leitão) e tive 0 espigas. Nestas alturas é bom ter um carimbo da SUN a dizer que aquilo funciona em todo o lado.
Mas claro, tens razão, se queres/tens de desenvolver em .Net, stick with Windows.
---
Este espaço pode ser seu... |
| | | | Finalmente estamos a chegar a um lugar comum....
Eu quero continuar a usar a FrameWork .NET e não quero me colocar ao Window$. Penso que a alternativa está a aparecer e eu simplesmente a quero agarrar e a alternativa é Mono.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | Eu quero continuar a usar a FrameWork .NET e não quero me colocar ao Window$.
Lamento. O .NET é uma ferramenta de lock-in da Microsoft. Quem se mete por esse caminho a pensar que depois pode usar o Mono é parvo.
--
Carlos Rodrigues
|
| | | | Antes demais, te agradeço por teres baixado o nível da conversa.
Sim, de uma forma geral o código desenvolvido na framework .NET (sem contar do Windows.Forms) corre sem problemas no Mono.
Por vezes temos é que compilar no Mono para que corra convinientemente.
Não entendo porque achas que empresas como a Novell que, já detive mais de 90% do mercado mundial de rede, uns parvos .... se calhar é tudo uma questão de visão.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | Bom, se achas que afirmar o óbvio é baixar o nível da conversa...
Sim, de uma forma geral o código desenvolvido na framework .NET (sem contar do Windows.Forms) corre sem problemas no Mono.
Deixa-me refrasear o que disseste: "de uma forma geral os programas brinquedo correm sem problemas no Mono".
Por vezes temos é que compilar no Mono para que corra convinientemente.
Isto é um argumento a favor ou contra o Mono? Qual é o objectivo de um runtime que interpreta bytecodes, se esses bytecodes não funcionam em todas as implementações desse runtime?
O problema é que muita gente aponta o Mono como um .NET multiplataforma, quando não é nem nunca vai ser, o .NET da Microsoft estará sempre anos-luz à frente e continuará a ser muito difícil não fazer programas que só corram neste. O pior é que quanto se aponta este facto óbvio, há sempre quem venha a lume dizer que o Mono não tem como objectivo clonar o .NET... quando o plano de desenvolvimento torna isso óbvio.
Além do mais, não é diferente de pensar que o GCJ algum dia se vai tornar uma alternativa às VMs da Sun, IBM ou BEA. É estúpido, é como lutar contra moínhos de vento.
Não adianta dizer o contrário, quem desenvolve para a plataforma .NET em Windows vai ficar para sempre agarrado a ela.
Não entendo porque achas que empresas como a Novell que, já detive mais de 90% do mercado mundial de rede, uns parvos .... se calhar é tudo uma questão de visão.
Tens razão deteve. Se não tivessem comprado a SuSE, ainda hoje a maioria das pessoas pensava que já não existiam.
Mas o Mono não começou na Novell, começou na Ximian a partir da cabeça do Miguel de Icaza, o que diz tudo sobre a viabilidade do projecto.
Só espero que a malta do GNOME não se lembre de se casar com o Mono, depois do fracasso estrondoso do Bonobo o projecto passa muito bem sem o contributo do Miguel de Icaza.
--
Carlos Rodrigues
|
| | | | | Baixar o nível é chamar parvo a alguém, só por ter escolhas que não são da tua preferência. Deixa-me refrasear o que disseste: "de uma forma geral os programas brinquedo correm sem problemas no Mono". Ham... assim de repente lembrei-me que o Mono corre o último Eclipse (sim, o Mono também corre Java). Mas podias dar exemplos de aplicações não brinquedo que não corram no Mono? Já que andas tão por dentro da plataforma agradecia. :-) O problema é que muita gente aponta o Mono como um .NET multiplataforma, quando não é nem nunca vai ser Bem, mas o Mono *é* uma implementação multiplataforma do .NET. Podes instalar o Mono no Windows, no Linux, no Mac OS X, etc. Se não é 100% compatível com outras implementações, isso já é outro problema. Se há certos módulos que ainda não estão acabados, as coisas não se fazem em 3 dias. Eu acho cómicos os teus posts sempre a apontar dedos, a dizer mal de toda a gente, a criticar sem mais nem menos só porque sim. O que é que tu conheces do Mono para estar a falar assim da plataforma e estar a denegrir o trabalho de tanta gente? Que experiência é que tu tens com o Mono? *Nenhuma* e andas a mandar postas de pescada com base no que lês noutros sitios facciosos ou com base na tua embirrância pessoal. Leste 2 ou 3 chavões e agora falas deles em todos os posts que tocam o Mono.
____________________
Pedro Santos :: psantos.net |
| | | | Baixar o nível é chamar parvo a alguém, só por ter escolhas que não são da tua preferência.
A carapuça enfia-a quem quer. Eu não lhe chamei parvo, portanto se ele quis interpretar a minha frase como um ataque pessoal, não é problema meu.
Ham... assim de repente lembrei-me que o Mono corre o último Eclipse (sim, o Mono também corre Java).
Sem alterações nenhumas? Duvido um bocado, uma vez que nem o gcj o conseguia fazer. A não ser que use as classes da Sun, mas nesse caso importas-te de me explicar qual é o interesse?
Mas podias dar exemplos de aplicações não brinquedo que não corram no Mono? Já que andas tão por dentro da plataforma agradecia. :-)
Chama-se a isso virar o bico ao prego. Considerando que o Mono está longe de implementar completamente o .NET da Microsoft, mostra-me tu uma aplicação .NET interessante (originalmente desenvolvida para MS) que corra no Mono.
Bem, mas o Mono *é* uma implementação multiplataforma do .NET. Podes instalar o Mono no Windows, no Linux, no Mac OS X, etc. Se não é 100% compatível com outras implementações, isso já é outro problema. Se há certos módulos que ainda não estão acabados, as coisas não se fazem em 3 dias.
Ah pois, mas não te esqueças que a Microsoft tem muito mais recursos alocados ao seu .NET do que a Novell ao Mono. E quando o Mono o alcançar, a Microsoft já vai levar umas quantas voltas de avanço.
Além disso, a compatibilidade é importante sim, porque será sempre esse o apelo do Mono. O Mono como plataforma nova e independente é irrelevante, não traz nada de novo e não vai conseguir criar uma comunidade suficiente para sobreviver sozinho, porque nem sequer é algo de novo e atraente por si só, é uma implementação coxa de uma plataforma da Microsoft.
Portanto, e como já me ouviste dizer inúmeras vezes, o pessoal mal informado (daí parvo, deviam informar-se convenientemente antes de tomarem decisões, a não ser que seja apenas uma desculpa para não os apontarem como mais uma vítima do lock-in da Microsoft) vai continuar a desenvolver para .NET e a dizer que depois, quando quiser fugir ao Windows, pode migrar para o Mono. E no dia em que sair o Longhorn, com o seu ênfase acrescido no .NET, o Mono vai ser ficar ainda mais longe da Microsoft, de forma irreversível.
O que é que tu conheces do Mono para estar a falar assim da plataforma e estar a denegrir o trabalho de tanta gente? Que experiência é que tu tens com o Mono? *Nenhuma* e andas a mandar postas de pescada com base no que lês noutros sitios facciosos ou com base na tua embirrância pessoal. Leste 2 ou 3 chavões e agora falas deles em todos os posts que tocam o Mono.
Exactamente, a minha embirrância vem daquilo que leio, porque na sua maioria (99%) são artigos de tipos que acham que pode vir a ser uma forma de permitir às empresas que desenvolvem em .NET libertarem-se da Microsoft e poder usar Linux e tal, e isso só reforça a minha opinião de que o Mono é nocivo para o Linux.
Neste tipo de plataformas ou há 100% de compatibilidade ou não há nenhuma. Basta ser necessário alterar uma linha a uma aplicação .NET para a meter a correr no Mono para a maioria das empresas não o fazer. Uma linha significa duas versões diferentes da aplicação e dores de cabeça adicionais no suporte.
Se querem desenvolver em .NET não os posso impedir, mas não andem por aí a vender banha da cobra com o Mono.
PS: lá por muita gente trabalhar nisso não quer dizer que seja bom. O Bonobo também envolveu muita gente e depois deste tempo todo está a ser removido como um tumor.
--
Carlos Rodrigues
|
| | | | | Bem, não sei qual é o teu conceito de interessante. O MonoDevelop pode ser um exemplo, teve como base o SharpDevelop(uma bela IDE por sinal) e que foi adaptado para GTK#. O NAnt, o NCruiseControl, o NUnit e o NDoc são outros exemplos. Deves conhecer estas ferramentas já que são clones de outras que já existiam em Java. São muito usadas e apregoadas no mundo .NET. Aqui tens outros exemplos em que destaco os ASP.NET Forums. A frio não estou a ver mais exemplos. O objectivo de correr o Eclipse, é para mostrar a interoperabilidade .NET/Java. Quanto às empresas que desenvolvem .NET migrarem para Linux, depende de muitos factores. Aplicações web que não necessitem de Entreprise Services praticamente podem correr num servidor web do mono sem problemas. E digo isto com base na minha experiência pessoal. Já que um windows custa dinheiro, não faz mal nenhum substitui-lo por um linux num PC qualquer a correr o NCruiseControl+NAnt+etc e tal. Uma aplicação web também já pode correr no Mono, por isso, já muita gente podia migrar para o Mono. Se discordas, então passo-te a bola e diz-me porquê. E sim, o Mono não vai correr tudo, mas já corre muita coisa que não necessite directamente do Windows ou de COM+.
____________________
Pedro Santos :: psantos.net |
| | | | | Não sei se já sabes, mas após as alterações que a Red Hat incluiu no GCJ e no Classpath, eles criaram com sucesso um port do Eclipse para se compilado com o GCJ.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Sei, também sei que implicou algumas alterações mais ou menos sérias no Eclipse. Eu simplesmente não gosto do GCJ, nem acho que tenha utilidade.
--
Carlos Rodrigues
|
| | | | Isto é um argumento a favor ou contra o Mono? Qual é o objectivo de um runtime que interpreta bytecodes, se esses bytecodes não funcionam em todas as implementações desse runtime?
Eu desenvolvo aplicações para HP-UX e devo te dizer que eu apesar de estar a desenvolver código em ANSI C, numa máquina identica e com o mesmo Patch Level que a máquina do cliente, já aconteceu levar o binário e ele simplesmente não correr na máquina do cliente.
Foi necessário complicar localmente para que ficasse a correr.
Pegando na tua afirmação infeliz, creio que seja um ponto a favor do Mono, pois, isso indica que o único problema é por vezes a linkagem que é diferente de SO para SO e não a linguagem em sim.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | uma máquina identica e com o mesmo Patch Level que a máquina do cliente, já aconteceu levar o binário e ele simplesmente não correr na máquina do cliente.
É óbvio que não são idênticas, senão corria...
Pegando na tua afirmação infeliz, creio que seja um ponto a favor do Mono, pois, isso indica que o único problema é por vezes a linkagem que é diferente de SO para SO e não a linguagem em sim.
Num runtime com bytecodes não há linkagem. O objectivo é mesmo correr em todo o lado, senão usava-se código nativo, ou não? Se é preciso recompilar está estragado.
--
Carlos Rodrigues
|
| | | | É óbvio que não são idênticas, senão corria...
Não é assim tão óbvio. Mesmo no cliente entre a máquina de desenvolvimento e produção, com tudo idêntico, havia necessidade de compilar na máquina de destino... cenas do HP-UX e nem por isso passa a ser um pior sistema.
O objectivo é mesmo correr em todo o lado, senão usava-se código nativo, ou não?
Não, o objectivo (segundo o meu entendimento) é poder usar o mesmo código. A posição da Novell em relação à integração do Mono e .NET sempre foi, o código é o mesmo sendo possível por vezes ter que ser compilado no sistema de destino devido a diferenças nas frameworks Mono e .NET.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | | A m$ só vai permitir isto enquanto o Java for uma ameaça, assim que o .net tiver arrasado todas as outras frameworks e toda gente estiver a programar em .net, vais ver se a m$ não começa a introduzir incompatibilidades, violar standards, etc...
Não sejas injenuo, eles sempre fizeram isto, não há razão nenhuma que desta vez não vão fazer o mesmo.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | | É tudo uma questão de perspectivas: quem me dera, um dia quem sabe, chegar a uma linux-shop com um windows e integrar automáticamente na autenticação LDAP, nos shares NFS, poder usar o GNU Arch... oh well :) Consegues tudo isso com Windows. Aliás,é bem mais fácil integrar um windows numa *nix shop do que o contrário e a própria MS fornece tudo o que é preciso... e de borla. Se calhar andamos é a atacar o problema da forma errada. Em vez de tentarmos integrar os nossos linuxes com o Windows podemos é comerçar a pensar ao crontrário...
|
| | | | | Só por curiosidade, o que entendes por Entreprise Ready? É que este semestre eu dei os Entreprise Services do .NET (equiparado ao J2EE, aliás, também tocámos nessa tecnologia) e os Entreprise Services não são mais que uma camada sobre COM+. Muito mais elegante, diga-se de passagem. Portanto, dizeres que o .NET não é Entreprise Ready é o mesmo que dizeres que o COM+ não é entreprise ready. Posso ser eu que não estou a ver o filme todo (afinal sou só um estudante), por isso esclarece-me! :-) Quanto à IDE, é importante. Eu em casa estou habituado a trabalhar sem as maravilhas de um debugger como deve ser, uso basicamente testes unitários para colmatar a falta do debugger. Contudo, há situações em que um debugger dá *muito* jeito e aumenta signitivamente a produtividade, não podes dizer o contrário. Por outro lado constato que os meus colegas que sempre viveram com o VS .NET já não passam sem ele e, por vezes, nem sabem usar um debugger da melhor forma e nos casos mais apropriados. Sejamos francos, é o debugger que vende o VS.NET... E naturalmente os utilizadores ficam viciados nessa IDE e 1) pensam que não existe mundo sem o VS .NET 2) nem querem saber das alternativas. Quanto ao Visio... até os meus colegas pró-MS o trocaram pelo ArgoUML, portanto, I rest my case. Portanto, como o esqueleto disse, tem de haver ferramentas de desenvolvimento de qualidade e suporte para o Linux para que alguém use Linux sem ter de gostar dele. Ainda no outro dia instalei o MySQL Query Browser no windows, um installer todo pipi, tudo a funcionar num instante. Fiz o download para o Linux, já não me correu. Faltava-lhe a lib XPTO versão 3 e eu tenho a lib XPTO versão 4! Tipo, não pode ser... gostam de chatear o pessoal... falam falam mas não funciona nada... O Mozilla Calendar quando o corro manda-me o Firefox abaixo... não pode ser... parece mal...
____________________
Pedro Santos :: psantos.net |
| | | | Desculpa a pergunta ... mas que raio de distribuição usas?
Algo tipo ... equivalente a windows beta?
--- não estou a defender o windows, estou exactamente a querer dizer que há mto ppl a usar versões instaveis.
Cumps-
Gass |
| | | | | Lol, por acaso agora estou a usar o Ubuntu, que é beta :-). Antes usava o Mandrake 10 e ainda tinha mais problemas... mas muitos mais! Presumo que o teu comentário se deva ao problema com o MySQL Query Browser. Eu na minha experiência com linux já passei pelo problema de me pedirem a ver são X e eu ter a X+1 N vezes! A maior parte delas no Mandrake. Lá tinha eu de fazer um ln para enganar as aplicações... um bocado complicado de mais só para instalar um programa. Isto nunca mais se passou desde que começei a usar o apt-get. Mas o MySQL Browser não está no apt-get. É uma coisa que não percebo, porque não há um installer que funcione para todas as distribuições?
____________________
Pedro Santos :: psantos.net |
| | | | Por acaso também estou a usar o Ubuntu... 0 problemo com o Mozilla Calendar.
Nem sei do que falas relativamente ao Query Browser por isso vou-me manter na minha insignificância... de qualquer dos modos experimenta o TOra.
---
Este espaço pode ser seu... |
| | | | Estás a "Warty Warthog" ou a versão unstable?
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| | | | | | Warty não é uma versão de desenvolvimento.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | É uma coisa que não percebo, porque não há um installer que funcione para todas as distribuições? Hey, ele há, para muitas aplicações é: ./configure && make && make install ;) Agora a sério, também já tenho tido aborrecimentos com versões de bibliotecas, mas nornalmente eles não acontecem quando a tua distribuição tem um bom sistema para gestão de pacotes, como provávelmente já deves saber. Now... instalar software à rés-vés do package manager, isto é, software desconhecido para o qual não há a instalação para uma dada distro, ou software proprietário que normalmente vêm com aqueles instaladores todos eye candy (os pesadelos que tive com o Oracle9i...), isto sim, é trabalho. O problema, do meu ponto de vista, nem é o instalador em si, em termos de usabilidade são funcionais e no que toca a copiar ficheiros de um lado para o outro, criar configurações, etc, fazem tão bem como qualquer outro para windows. O problema de falhar uma library qualquer é aquele que é comum para qualquer aplicação, seja compilada, rpmada, etc. No fundo é tudo uma questão da falta de padronização no que se refere às convenções adoptadas pelas diferentes distribuições: sistema de ficheiros (/opt ou /usr/local?, /lib/firmware/ ou /usr/lib/firmware/?), convenções de naming e outras considerações. No windows é tudo muito mais fácil. Se queres distribuir o teu software apenas tens que colocar na caixa, na secção dos requirements, que corre sobre uma plataforma WinXPTO, eventualmente que precisa de um Runtime Environment de JAVA (e porque não incluir bundled com o software?), e certificares-te que, para cada biblioteca extra, ou framework que tenhas usado, distribuis de igual modo os binários necessários (na sua versão correcta, nem tem que ser a mais recente). Tudo funciona à primeira, contando, claro, que não o tentes instalar numa versão antiga do Windows, que não cumpra a API que usas no teu Software. O tradeoff óbvio é que para 5 aplicações que usem, exemplo, a libXPTO, podes ter esta lib 5 vezes em disco, resultando redundância, isto é, menos mp3 em disco.
Is this desire? |
| | | | "os pesadelos que tive com o Oracle9i"
Então experimenta instalar o DB2! :-D
"resultando redundância, isto é, menos mp3 em disco."
Menos Pr0n, querias tu dizer :-P
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | | Pá se queres uma coisa estavel porque não usas o Warty? Não podes estár à espera de usar o Hoary e que te corra tudo bem... Installares, são uma solução inferior ao Gestor de Pacotes, e se a distribuição cumprir o Linux Standard Base, vai ter lá o RPM.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Os 10 ou 15 minutos que perdias a verificar o problema sobre a biblioteca/depêndencia em falta iriam ser compensados com os consecutivos crashes e rebootes que terás que fazer no Windows. Nunca serão melhor as coisas que dão menos trabalho..pensa nisso!:)
..may the source be with you =) |
| | | | | Pah eu não sei que Windows utilizas, pela descrição parece um 95/98. Eu nunca tive um crash num Windows XP, mas já tive vários no Mandrake 10, essa é que é essa. Portanto, acho que o pessoal devia mudar de discurso que esse já não pega, estar com argumentos dessas ultrapassados não te leva a lado nenhum! :-) E a solução foi mesmo continuar a utilizar o MySQL CC, que se porta lindamente.
____________________
Pedro Santos :: psantos.net |
| | | | Deves ser o único que ainda nao crashou o XP..Os meus sinceros parabens!
..may the source be with you =) |
| | | | Já lixei o meu Linux muitas vezes e consigo sempre recuperá-lo. Nunca o crashei a não ser quando me meti a experimentar com módulos de kernel não testados, o que é natural.
Pois o Windows, já crashei todas as versões dele. Até o XP, que eu pensava que era seguro, crasha.
|
| | | | Pois é, mas isso é a tua experiência. Eu nunca crashei um XP e já crashei vários Linuxes, e não foi a mexer nos kernels. :-)
____________________
Pedro Santos :: psantos.net |
| | | | ? Como?
---
Este espaço pode ser seu... |
| | | | Quando estava a desenvolver algo, com aplicações mais pesadas abertas, por exemplo. Mas isto era no Mandrake, no Ubunto nunca me aconteceu. Se bem que quando eu puxo por ele fica uns belos momentos sem responder.
____________________
Pedro Santos :: psantos.net |
| | | | Oh well, se te serve de consolo, eu não consigo compilar duas vezes seguidas o Eclipse 3.0.1 no Windows XP... a 1a compila e depois deixa o sistema num estado lastimoso (imagina o XP num PII a 300 se tanto).
Deve ter qq coisa a ver com a gestão da memória virtual, porque a compilação chupa memória que é uma coisa parva... o computador tem 512 de Ram se é que interessa.
---
Este espaço pode ser seu... |
| | | | Isso é muito estranho... se tivesse a ver com dispositivos acreditava que o crash fosse ao nível do kernel, mas por causa de aplicações duvido. O mais provavel é ter sido o X Server a rebentar totalmente.
Chegaste a tentar pingar a maquina ou a fazer login por ssh?
Já me aconteceu várias vezes o X Server crashar (e nem o Ctrl-Alt-Backspace/Fn responder), e conseguir reiniciar por ssh, ou simplesmente desligar o computador normalmente carregando no Power Button - que envia um evento ACPI directamente ao kernel, sem passar pelo X.
Se bem que quando eu puxo por ele fica uns belos momentos sem responder.
Bem, acho que isso já depende mais do HW do que do SO.
Mas se comparares a responsividade, em situações de load elevado dum Linux 2.6 preemptivo, com a dum XP no mesmo PC, coitadinho do XP...
Eu no meu portátil (Athlon XP 2000+ com 704 MB de memória) consigo estar por exemplo compilar o Mozilla no Linux e ao mesmo tempo a usar o sistema normalmente, ou seja, ouvir música sem skips e usar os restantes programas sem que o rato deixe de responder.
Já no Windows XP a coisa não é bem assim. Não costumo usá-lo, mas quando uso noto bastante bem uma performance e responsividade inferiores. Acontece frequentemente o rato ficar uns momentos sem responder só por estar a abrir um programa ou a instalar qualquer coisa ou fazer WinUpdate.
E convém notar que o PC tem o autocolante "designed for Windows XP"... ;-)
"As you know, these are open forums, you're able to come and listen to what I have to say."
--George W. Bush |
| | | | Não, não cheguei a fazer nada. E não disse em lado nenhum que o meu windows se portava melhor! ;-)
____________________
Pedro Santos :: psantos.net |
| | | | | Pois o que ele disse é normal. Eu nunca tive crashes do Linux, mas lembro-me que tive algumas situações (poucas, menos de 10) em que o X deixava de responder, nessas alturas ia a outra máquina ligava-me por ssh e resolvia o problema em alguns segundos.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Podes ter problemas de hardware.. o linux é mais senvível, não é à lá windows que deixa passar tudo.. tipo html mal feito no internet explorer. Um amigo meu corre win xp e o linux a ele crasha.. não é nenhuma máquina recente. são coisas da vida :) o meu linux não crasha e o win xp no work também nunca crashei, mas também não invento lá muito, pois é para trabalhar e programar.
Characteristic of life style... |
| | | | o linux é mais senvível, não é à lá windows que deixa passar tudo..
Que parvoíce... fdx ter problemas e a malta sentir-se "impotente" para os perceber é coisa que me deixa com comichão, tenhas ou não tenhas o source code... tens um debbuger para quê? mete as mãos na massa e toca a tentar perceber onde está o problema.
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | A máquina além de não ser minha, não é grande coisa e o dono não teve para se chatear muito com isso.. o problema é que agora também lhe dá problemas com o SP2 do WinXP.. tem a ver com a placa gráfica pelos vistos que é onboard. É o que dá comprarem pc's tipo worten e depois mais tarde arrependem-se com a porcaria de componentes que compraram =)
Characteristic of life style... |
| | | | | Eu nas aulas já tive e vi varios crashes do xp, e fora delas já vi outras pessoas a terem. É um facto que acontecem. E nunca em 4 anos de utilização tive um crash do sistema em GNU/Linux.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Basta de bater no ceguinho. O facto é que quem já usou Mandrake 10.0 sabe do que o PRE está a falar.
Nunca cheguei a perceber se era um problema do X, drivers da nvidia, artsd, dunno. Mas o 10.1 está *muito* mais estável -- nunca me estourou.
<shame>Houve menos abstenção no Iraque do que a que há em Portugal.</shame> |
| | | | Qdo ao mandrake, e aos fedora e essas distros mais newbie-oriented não sei, mas tenho uma instalacao de Slackware 8.1 que passou para o 9 e agora para o 10 a partir de updates. Ainda não tive um único crash em 2 anos de utilização. Estive um kernel panic uma vez devido a problemas com a memória! :). Mas estável que isto só mesmo o WinME :P
..may the source be with you =) |
| | | | Porra, és um gajo cheio de sorte....
Tenho de facto menos crashes do Linux do que no XP.... mas o XP está incrivelmente mais estável do que as versões anteriores.....
Já repararam que quem critica o Windows nunca tem problemas com o Linux e vice-versa? Que coincidência... só pode ser coincidência...
Uso Linux 80% do meu tempo em casa e 90% no trabalho, os crashes do Windows são RARÍSSIMOS.... será que isso faz de mim um Windows lover? :)
Yours,
McB!
They told me it need Windows 95 or better, so I chose Linux |
| | | | Bem.. não é bem assim ....
1º não se gastou simplesmente 10 ou 15 minutos
2º Nem devia ter esse erro.
Mas o problema real não é este. Não se pretende com esta thread discutir se em que ponto é que o Linux é melhor que o Window$, pois, pelo que parece ser a ideia generalizada, o Linux é francamente melhor, isto éo quadro apresentado é francamente mais bonito que o do Window$.
Mas, contrariamente, o que os mais radicais nesta temática afirmam, ainda à alguns pontos a melhorar e a resolução das dependências é uma delas.
Ainda me recordo, no Window$95/98, que era necessário resolver problemas de IRQs dos diversos devices. Felizmente essa gestão foi agilizada e neste momento no Window$ não temos esse tipo de problema. No caso do linux o problema das dependências é enorme, pois, a filosofia é: num package de instalação é incluido simplesmente op código fonte (ou binários) da aplicação em causa, mas, para esta aplicação correr (ou ser instalada) é necessário que outras coisas já estejam instaladas no sistema. Por vezes esta gestão de dependências é complicada de gerir, especialmente quando não estamos a usar os gestores de pacotes como Emerge, apt-get, urpmi, etc.
É verdade que eu até não me importo de ter o trabalho de tentar resolver essas dependências todas, e ter tudo a funcionar como acho que quero, mas, imaginem a minha mulher que de computadores nada percebe e que tudo que seja mais complicado que fazer download para o desktop e duplo-click para instalar é muito complicado, como é que lhe meto na cabeça que para instalar software vai pela linha de comando ou pelo Sympatic. E se não estiver nos repositórios ela tem que fazer download das sources e seguir o normal configure && make && make install.
Temos que ser realista que este tipo de deployment não é o indicado para um sistema que pretendemos que seja difundido para todos. Não podemos esquecer que as pessoas não nascem ensinadas, muito menos para as novas tecnologias e muito menos para o uso de um sistema como o Linux.
Somos realistas quando afirmamos que o Window$, ainda é, como sistema Desktop um sistema mais refinado e virado para a utilização do tipo End-User.
Felizmente o Linux está a ir no bom caminho, mas, ainda há muito para percorrer e com a entrada de grandes empresas como a Novell e a IBM a divulgar largamente o Linux, a desenvolver novas funcionalidades e melhorias, tenho a certeza que dentro em breve (2 anos) teremos uma distribuição que ultrapassará o Winodw$ em facilidade de utilização.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | Não deixas de ter razão.
Às vezes (não muito frequentemente, convenhamos) ponho-me a pensar: o que seria do Linux se existessem tantas publicações (livros/revistas) a explicar como funciona este SO (e suas aplicações) como as que existem para o Windows.
É que por vezes tendemos a exagerar e a pensar que o Windows é tão user-friendly que nem são precisos cursos básicos (mas eles existem!) nem manuais (mas eles existem abundantemente!), e que qualquer joe-user (aka secretária-que-usa-o-processador-de-texto-para-escrever-meia-dúzia-de-linhas) sabe trabalhar com o Windows.
Quanto à produtividade, é verdade que tendemos a resolver melhor os problemas consoante a habituação e domínio que temos das ferramentas ao nosso dispor.
Eu, por exemplo, seria mais improdutivo se por alguma razão tivesse de trabalhar em plataforma Windows e com as suas aplicações.
Admito perfeitamente que outros sintam o mesmo em relação ao Linux ou ao Unix. Não me choca. Não me venham é vender a treta de que se é mais produtivo em geral nesta ou naquela plataforma.
Aqueles que dizem isso, provavelmente são IMprodutivos em qualquer plataforma.
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | Sim ... às vezes penso nisto também e só depende de nós exigirmos essas publicações ou até mesmo desenvolvermos nós.
Por exemplo, criei um WIKI no meu servido em casa, onde coloco todas as minha notas sobre administração e desenvolvimento, desta forma, outros que tiveram ou tem as mesmas dúvidas que eu, podem lá consultar o problema e como o resolvi.
Visita aqui, serás bem vindo a ajudar.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | | Eu, por exemplo, seria mais improdutivo se por alguma razão tivesse de trabalhar em plataforma Windows e com as suas aplicações.(...)Não me venham é vender a treta de que se é mais produtivo em geral nesta ou naquela plataforma. Aqueles que dizem isso, provavelmente são IMprodutivos em qualquer plataforma.
100% de acordo
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| | | | As pessoas confundem "fácil de usar" com "já conheço".
"It is every citizen's final duty to go into the tanks and become one with all the people."
- Chairman Sheng-ji Yang, "Ethics for Tomorrow" |
| | | | | Ainda me recordo, no Window$95/98, que era necessário resolver problemas de IRQs dos diversos devices. Felizmente essa gestão foi agilizada e neste momento no Window$ não temos esse tipo de problema Espero que não estejas a comparar as dependências com os shares de IRQs. o problema de IRQ's do Win9x é do kernel! e isso é outra história :) Por vezes esta gestão de dependências é complicada de gerir, especialmente quando não estamos a usar os gestores de pacotes como Emerge, apt-get, urpmi, etc. Sim tens razão principalmente quando as depêndencias são exóticas. Mas não me parece que a instalacao do MySQL seja para o End-User. Não podemos esquecer que as pessoas não nascem ensinadas, muito menos para as novas tecnologias e muito menos para o uso de um sistema como o Linux. As pessoas tambem não nascem ensinadas a usar Windows! Qto a mim..a facilidade de utilização não me afecta, nao me importo de ter algum trabalho para ter as coisas afinadas e a funcionar decentemente, mas compreendo que o GNU/Linux tem um bom caminho a percorrer até alcançar um bom desktop como o MacOSX por exemplo.
..may the source be with you =) |
| | | | Já não estava a falar da instalação do MySQL mas das instalações em geral, apesar de ter sido esse o trigger de dispultou esta conversa.
É verdade que as pessoas não estão ensindas a usar Window$, mas, o facto de terem usado uma vez só, faz com que mudar para linux seja um tanto ou quanto complicado.
Espero sinceramente que essa diferença seja culmatada em breve e que deixe se haver diferenças.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | É verdade que as pessoas não estão ensindas a usar Window$, mas, o facto de terem usado uma vez só, faz com que mudar para linux seja um tanto ou quanto complicado. Não se forem excluidas do processo de instalação, manutenção, e se lhes puserem à frente versões estáveis, "de produção", dos diversos Softwares, dos quais dependem, os quais usam para fazer as vidas delas. Não estou ciente de nenhum estudo, nem me posso apoiar em nada credivel. Por isso, em maneiras de posta de pescada, apenas deixo a minha afirmação que: epá, numa empresa, numa escola, numa administração pública, onde há um browser, um Word Editor, uma folha de cálculo, um MSN, um cliente de email; onde os PCS são todos iguais; onde os utilizadores são todos iguais; como não adoptar uma solução Linux+OOFice+Whetever quando entra pelos olhos que, mesmo não a curto prazo, há claras vantagens económicas, legais, éticas, culturais e, porque não, religiosas (multiplicação dos peixes e do pão?)? As empresas, no fundo, não são mais do que as pessoas que as formam e as integram. A inércia é a mesma, a apatia é a mesma, a preguiça, esta, de tal modo empregnada que nem as vantagens económicas de uma boa solução a quebra. Isto, claro, sempre que há demasiados meios para atingir um fim.
Is this desire? |
| | | | O OO é apenas um substituto genérico do MSOffice, há situações em que a única vantagem se reduz ao preço. Fui utilizador de msoffice durante muitos anos e actualmente (desde que saiu a versão 1.1) uso o OO para quase todo o tipo de trabalho. Não obstante, há situações em que este não serve, nomeadamente quando lido com documentos de grandes dimensões (>12.000 páginas) ou preciso de tabelas mais sofisticadas. Por outro lado, concordo genericamente com o que afirmas. Sou da opinião que deveria haver uma política de migração mais agressiva nas instituições públicas.
|
| | | | Ora ai está um problema enorme do OOffice .... quando temos tabelas complicadas (com merges e imagens) e queremos copiar o conteúdo para outra célula ou outra tabela ... o OO faz PUFFFFF não diz nada .. não grava .. nada ... simplesmente PUFFFFF
Gosto do OO e não vou deixar de usar ... mas ele não é à prova de bala ..
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | De facto, com a última 1.9 tentei abrir um .doc que me enviaram com 20mb e o OOo não abre nem à lei da bala... fica ali a mastigar, mastigar memória :(
Espero que resolvam o problema :)
---
Este espaço pode ser seu... |
| | | | Va lá pega no código e resolve já ;o) onde anda esse voluntarismo todo? E a rapidez na resolução ;o)
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | Rapidez na resolução do quê? De um problema numa versão beta?
Logo se vê na final... agora vai tomar um duche de água fria a ver se arrefeces.
---
Este espaço pode ser seu... |
| | | | Até parece que é só na versão beta... humm nahh, és mesmo credível lololol
Logo se vê na final... Já reportaste? ou és daqueles que ah já alguém passou ou vai passar por isto... ;o) Aqui por PT há muitos com esse espirito
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | No fim de uma semana de trabalho, só posso julgar que já estás tão queimado que tens de libertar o stress para algum lado. Estás desculpado.
O bug: não acredito que haja muita gente a abrir .doc's de 20 e tal mb.
---
Este espaço pode ser seu... |
| | | | De facto, desta vez acho que foste longe demais...
Aprende a ter calminha...
O facto do OO não ser à prova de bala não o impediu de fazer uma tese de mestrado nele. Já sei que 100 páginas não são 12000 páginas, mas garanto-te que é mais do que suficiente para 90% de quem usa o MSOFfice.
Vê se te acalmas... Até acredito que o BUG esteja reportado, mas também acredito que haja bugs mais sérios a resolver antes!
Yours,
McB!
They told me it need Windows 95 or better, so I chose Linux |
| | | | Obrigado pela sugestão... sinto-me muito melhor agora ;o)
O facto do OO não ser à prova de bala não o impediu de fazer uma tese de mestrado nele
Não é o Oo nem nenhum outro produto... apenas aproveitei para por à prova alguns argumentos que são normalmente arremessados em relação às vantagens do modelo de desenvolvimento... Podes pensar neste meu comentário sempre que encontrares um problema num produto e não o consigas resolver em poucas horas, nem em poucos dias... ;o)
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | Tu que és tão íntimo com a MS e com o Bill Gates podias arranjar as especificações do formato .doc em vez de estares praí a mandar palpites. ;-)
Aí sim, farias algo de útil pela sociedade. :-)
"As you know, these are open forums, you're able to come and listen to what I have to say."
--George W. Bush |
| | | | Não precisas de mim para nada, tenta mailto:mswhish@microsoft.com e pede para abrirem o formato pode ser que para ti funcione ;o) acho que a minha acção na sociedade é bem mais importante noutras áreas, e tenho feito por isso...
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | Tenho usado a 1.9 em Windows e esperemos que a estabilidade da versão final seja bem superior. A maneira mais simples de sair do processador de textos é fazer um "paste" de alguns tipos de dados :) Outra coisa impressionante no 1.9 é o consumo de memória e a lentidão geral dos programas. Sinceramente não me dei ao trabalho de ver, mas penso que aquilo deve estar compilado com informação de debug. Os pontos positivos são sem dúvida o OO Base para lidar com bases de dados a-la Access, e as modificações a nível de interface - sem dúvida, mais eye-candy.
|
| | | | No caso do linux o problema das dependências é enorme, pois, a filosofia é: num package de instalação é incluido simplesmente op código fonte (ou binários) da aplicação em causa, mas, para esta aplicação correr (ou ser instalada) é necessário que outras coisas já estejam instaladas no sistema. Been there... o Oracle9i distribuia uma versão JRE da Sun que tentava usar sempre que o instalador era invocado, felizmente, neste caso, dava para resolver apagando o JRE da hierarquia do Oracle e criando um link simbólico, no mesmo local, para o JRE no sistema (que no meu caso era o da blackdown). Mas depois surgia outro problema que era faltar uma compat-libstdc++, e ainda outro que se prendia com a shared memory, tinha-se que invocar uma sysctl qualquer. Mas isto tudo porque eu uso uma distribuição que não foi tida em conta para o processo de intalação do Oracle. A instalação funcionava de facto, confirmado por alguns colegas, nas distribuições que vinham nos requisitos do instalador (Redhat, Mandrake e Suse - apenas algumas das versões), ora, o ideal aqui seria haver um layer de compatibilidade entre todas as distribuições, layer que o Windows não precisa, afinal, o Windows é apenas o Windows.
Is this desire? |
| | | | | Ainda me recordo, no Window$95/98, que era necessário resolver problemas de IRQs dos diversos devices. Felizmente essa gestão foi agilizada e neste momento no Window$ não temos esse tipo de problema. Não esquecer que a agilização não foi só a nível do SO. A alocação automática de recursos sem os bugs horríveis das primeiras versões e a extinção do ISA/VBL foram os principais motivos do desaparecimento dos conflitos de IRQ's. Também a modificação substancial dos controladores pic na arquitectura pentium permitiu uma expansão do número de canais e uma melhor gestão de recursos, a anos-luz de distância do good ol' 8259. Em contrapartida, máquinas com controladores de 8 e 16 bit ISA sem pnp não funcionam em XP. Já tenho tido problema com controladores ISA que, mesmo com PnP, não são detectados. No caso do linux o problema das dependências é enorme, pois, a filosofia é: num package de instalação é incluido simplesmente op código fonte (ou binários) da aplicação em causa, mas, para esta aplicação correr (ou ser instalada) é necessário que outras coisas já estejam instaladas no sistema. Duas palavras: BSD ports :D
|
| | | | Como é que o .Net se porta em ambientes heterogeneos? Como é que o .Net se porta c/ grandes cargas? Qual é a escalabilidade horizontal do .Net com transacções? As versões futuras serão backwards-compatible?
Se alguém se importar que responda a isto, porque não acho respostas para estas perguntas no google.
---
Este espaço pode ser seu... |
| | | | Já agora este estudo embora com sponsorship da MS parece-me muito interessante na abordagem bem como os seus resultados ;o)
http://www.middlewareresearch.com/endeavors/040921IBMDOTNET/endeavor.jsp
E encontras aqui toda a documentação sobre a metodologia, código, configuração, otpimizações, etc.
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | Quanto às ferramentas, *há* ferramentas de qualidade para Linux... a malta quer é a borla, mas a borla eventualmente tem de acabar.
Tens por exemplo, o IntelliJ. Se fôr demasiado , sempre podes optar pelo Eclipse + N plugins (JBossIDE/Lomboz/XDoclets por exemplo).
Yup, não são IDE's para .Net... no one cares.
Para C/C++ então é uma fartura, mas o melhor é começar pelo KDevelop.
Eu já usei esse argumento do IDE, mas actualmente acho que é uma estupidez, gastarem-se centenas de contos numa ferramenta, porque o developer não quer perder 5 ou 10 minutos a ver como é que a coisa funciona num ambiente diferente.
A preguiça está instalada :\
---
Este espaço pode ser seu... |
| | | | >Yup, não são IDE's para .Net... no one cares. tens o X-Develop.
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | Essas centenas de contos ganhas podem ser depois desperdiçadas em perdas de produtividade. Já perdi milhares de horas de desenvolvimento por causa da forretice. Sugeri várias vezes a compra de ferramentas que ficariam pagas ao fim de um mês de trabalho, mas o PHB sabe lá disso, o que ele pensa imediatamente é que vai desperdiçar um monte de dinheiro num "gadget" para o pessoal brincar.
|
| | | | Estamos a falar de coisas diferentes: eu estou a falar de duas ferramentas que fazem o mesmo, com as mesmas capacidades, mas uma pisca assim e a outra pisca assado.
O programador está habituado a fazer o debug com o F5 e se vai ter de usar outra combinação de teclas, gera-se o pânico e ai jesus...
Pegando no exemplo do VS.Net, uma coisa que lhe achei útil na altura em que fiz o beta testing daquilo (sue me), foi o facto de um gajo lhe dar um URL e venha de lá o stub gerado automágicamente.
"Eia", pensei eu, "esta m*rda é mm boa e altamente produtiva... não há nada igual".
Aqui há umas semanas, já sendo um macaco um bocado mais velho, falaram-me de uma equipa que ainda não tinha decisão formada sobre o J2EE e o .Net e que um dos pesos na balança era a facilidade com que se ligavam a webservices no VS.Net.
As cenas não podiam continuar como estavam há uns anos atrás, por isso vamos lá ver o que o google diz e:
http://ws.apache.org/axis/java/user-guide.html#WSDL2Java
Agora, vens-me dizer que a consola te faz comichão ou outra porcaria qualquer do género?
O programador comichoso é o pior tipo de programador... na minha opinião.
Um gajo, ao fim do dia, trabalha com o que lhe dão, goste-se ou não. É para isso que nos pagam.
---
Este espaço pode ser seu... |
| | | | O programador comichoso é o pior tipo de programador... na minha opinião.
Não estarás tu a ser também comichoso ??? Com tantas pessoas a quererem esse tipo de funcionalidades para melhorares a sua perfomaçe e tu a achares que é perda de tempo que deviamos é voltar todos atràs aos cartões perfurados que nessa altura é que se fazia bons programas e boas análises etc..etc.. e que o debug de uma forma geral só trás lentidão e lixo aos nossos programas, o Code-Completation não tem qualquer valor, apesar de todos os IDE que sergem virem já com essa funcionalidade, retiras logo para nem olhares para ela como o diabo tem medo da Cruz...
Como já disse noutras respostas ... cada um tem o direito a escolher que tipo de plataforma pretende, seja ela boa ou má para ti e não é por isso que passa a ser pior programador.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | e os Entreprise Services não são mais que uma camada sobre COM+. Muito mais elegante, diga-se de passagem.
Qualquer coisa é mais elegante do que o COM...
--
Carlos Rodrigues
|
| | | | | Primeiro, não tenho possibilidade de usar os sistemas de GroupWere Groupware :)
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | Essa é a resposta óbvia, mas, claro que não é a resposta pretendida.
O pretendido é ter um sistema que seja "Universal" e Fiável. Não me parece que aqui na empresa pretendam mudar de Exchange para GroupWare porque eu gostaria de usar Linux como desktop. O ideal era que eu tivesse alternativa para usar o Linux no meu posto de trabalho e usar as ferramentas que estão no sistema onde Exchange e VSourceSave são um exemplo.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | Quantas pessoas trabalham na tua empresa?
---
Este espaço pode ser seu... |
| | | | no desenvolvimento .. umas 20
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | 20 pessoas? E *precisam* do Exchange para 20 pessoas?!? Oh meu amigo, escolhe um :)
http://www.kolab.org/
http://www.opengroupware.org/
e se quiserem muito poder dizer que têm suporte:
http://www.novell.com/products/openexchange/
---
Este espaço pode ser seu... |
| | | | 1º não sou eu que escolho nada ... é as chefias
2º Sou programador e não um System Administrator com poder de decisão.
3º a empresa faz parte de um grupo de empresas onde trabalham mais de 100 pessoas e o Exchange trata desses utilizadores todos e não só destas 20.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | 100 pessoas... peanuts. Se fossem 3000.
Mas cada um sabe de si e dos seus bolsos :)
---
Este espaço pode ser seu... |
| | | | Acho que ele só te estava a fazer uma correcção ortográfica.
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| | | | Agora olhando com mais atenção ... sim .. tens razão.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | Bom, apesar de eu não gostar particularmente do Mono...
Primeiro, não tenho possibilidade de usar os sistemas de GroupWere da Micro$oft (Exchange Server), ou as soluções que existem ainda são experimentais.
Tens o Connector para o Evolution, que nunca experimentei, portanto não sei se também suporta as funcionalidades de GroupWare. Seja como for tens sempre o Outlook Web Access.
Segundo, o Mono ainda não é uma solução de desenvolvimento, aceitável quando comparado com a plataforma .NET. É verdade que praticamente tudo está portado, mas, ainda à lacunas, especialmente no SOAP.
Concordo, Além disso acho que nunca irá ser.
Terceiro, o MonoDevelop ainda não é um aplicativo finalizado o que leva a uma grande falta de produtividade. Claro que esta comparação é feita em relação ao IDE do .NET.
Esta mania de associar a falta de IDEs a falta de produtividade só tem uma explicação: não conhecem as ferramentas com que trabalham e têm medo de desenvolver de uma forma diferente.
Eu só uso IDEs se for obrigado, nem mesmo para Java ou C/C++ onde existe o Eclipse, que é excelente. (Que também suporta C# sobre .NET ou Mono, ver como)
Alguém é capaz de me explicar o que é que se pode fazer com um IDE que não se possa fazer com ferramentas avulsas?
Quarto, ainda não à "port" do Source Save para linux. Sim eu sei que o CVS é bem melhor, mas, a integração do SS nos projectos .NET é fantastica apesar de não termos diversas funcionalidades como várias pessoas poderem alterar o mesmo ficheiro.
E qual é o problema de não ter SourceSafe em Linux? Se o problema for a integração em projectos que já o usam, podes sempre usar o SourceOffsite, que permite usar repositórios VSS a partir de várias plataformas.
Se não for este o caso, podes muito bem usar CVS, que funciona perfeitamente de dentro do Eclipse.
Se não quiseres usar o Eclipse, podes usar o CVS na linha de comandos, porque sinceramente não vejo a dificuldade de fazer "cvs up" e "cvs commit" manualmente...
Quinto, não existem aplicações de modelização capazes de ajudar os programadores. É verdade que temos o DIA, mas, convenhamos que o M$Visio está muito mais à frente deste aplicativo.
O Visio é dos melhores programas que a Microsoft vende, e já o era antes de eles o terem comprado. Mas tens o ArgoUML, que já aqui foi referido.
Adicionalmente, tens um monte de plugins de modelação para o Eclipse.
E todas as aplicações de gestão que posso comprar no supermecado ainda não correm em Linux. Apesar de já haver empresas que desenvolvem produtos exclusivamente para Linux, devido à procura ainda ser pouca, o desenvolvimento ainda é limitado.
É verdade, mas pensava que estávamos a falar de desenvolver em Mono + Linux, não de usar o Linux no desktop dos contabilistas e gestores...
Com esta estratégia da Novell, em portar a plataforma .NET para Linux, temos a possibilidade, dentro em breve, poder desenvolver no Window$ um aplicativo e poder realmente correr em quase todas as plataformas (SUN, HP, Linux, Max e Window$).
Eles não estão a portar, estão a clonar, e há uma grande diferença entre as duas. Não te iludas, nunca vais poder desenvolver em Windows e correr numa data de outras plataformas. Muito no .NET da Microsoft é completamente dependente do Windows e isso só irá ser reforçado com a chegada do Longhorn. O Mono não tem hipóteses.
O que poderá continuar a ser possível é desenvolver em Mono e correr no .NET da Microsoft, mas isso chama-se apontar para o mínimo denominador comum.
Claro que também temos o Java que já faz isto à muitos anos, mas, o facto de a plataforma .NET ser aberta, faz com que a sua evolução nos ultimos 2 anos tenham sido muito maior que a evolução do Java, comparativamente.
Oh meu Deus...!! Aberta, a plataforma .NET?! Se te referes ao facto de ser standard, sugiro-te um reality-check. O que está standardizado é completamente insuficiente para poder sequer chegar aos calcanhares da implementação da Microsoft. Até o Mono já está muito para além do standard.
Além do mais, o Java é muito mais aberto do que o .NET. Tens especificações detalhadas da VM publicadas, e nada te impede de criar uma nova implementação baseada nelas (algo que o GCJ ou o Kaffe fazem) e a linguagem também está suficientemente detalhada para poderes fazer compiladores alternativos (mais uma vez o GCJ, ou o Jikes).
Quanto à biblioteca de classes, também a podes reimplementar, basta ver o que andam a fazer os tipos envolvidos no projecto GNU Classpath.
Não creio que de futuro a Micro$oft venha a fechar o standard C#, pois, ela só tem a ganhar com a universalidade desta linguagem.
A Microsoft não precisa fechar o standard, porque o standard é irrelevante. Tudo o que interessa já está fechado e/ou dependente do Windows.
--
Carlos Rodrigues
|
| | | | "Alguém é capaz de me explicar o que é que se pode fazer com um IDE que não se possa fazer com ferramentas avulsas?"
Só por esta pergunta dava-te 5 pontos... se os tivesse!
Confesso que me fazem uma certa comichão aqueles programadores que não sabem programar sem a bengala do IDE.
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | Alguém é capaz de me explicar o que é que se pode fazer com um IDE que não se possa fazer com ferramentas avulsas?
eheheh aqui há uns meses propuz-me a deixar o joe de lado e usar exclusivamente o vi(m) (yeah I know, detestas o vi) e acho que é um editor potentíssimo para aquilo a que se propõe.
No entanto, eu "preciso" de ter uma imagem com a estrutura de classes à mão de semear. Preciso do code-insight para as minhas classes.
Mas se é para fazer qualquer coisa que consigo fazer de olhos fechados, nem penso sequer em executar o Eclipse (ou qualquer outro IDE).
Já para não falar em scripts perl, bash ou ficheiros de texto: aí é só vi.
---
Este espaço pode ser seu... |
| | | | "No entanto, eu "preciso" de ter uma imagem com a estrutura de classes à mão de semear. Preciso do code-insight para as minhas classes."
E tens a certeza que o Vim não faz isso (JavaBrowser, JavaDecompiler, JavaRun, JavaAPIDoc, etc)?
O única coisa que o Vim _ainda_ não faz é tirar imperiais :-D
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | | Alguém é capaz de me explicar o que é que se pode fazer com um IDE que não se possa fazer com ferramentas avulsas? Nunca usei o .NET nem MONO para projectos a sério. Mas pegando o Java. Não compares fazer debugging no jdb do que fazer no Eclipse. E isto deve-se aplicar à plataforma .NET (notepad vs Visual Studio)
|
| | | | Esse é outro problema, a toxicodependência do debugger. Como eu raramente uso debuggers (nos últimos 8 anos passei no máximo 2 horas a usar um debugger, e nunca em Java) não me afecta minimamente.
Mas para quem precisa mesmo deles, também existem ferramentas gráficas avulsas, inclusivé para Java... Por exemplo o JSwat.
--
Carlos Rodrigues
|
| | | | uh? Nunca usaste o gdb? apesar de não ser um debugger, também nunca usaste o strace? geez, não acredito :P
---
Este espaço pode ser seu... |
| | | | Eu não disse isso, eu disse que a soma do meu tempo a usar debuggers nos últimos 8 anos deve dar umas 2 horas. Portanto, o gdb cai nesse saco (e o strace também pode cair, não afecta a minha estimativa).
Eu prefiro sempre pensar naquilo que era suposto estar a acontecer e não naquilo que efectivamente está a acontecer. Portanto eu prefiro gastar 20 minutos recostado na cadeira a pensar do que 20 minutos a seguir a execução do programa. Quando pensar não é suficiente, metem-se uns printfs em locais estratégicos.
Eu já sei que muita gente acha isto herético, e que usar o debugger é 1337 e tal, mas eu não quero saber. Pensar sobre o código permite esborrachar mais bugs de cada vez, ter código mais correcto (por oposição a código que simplesmente passa os nossos testes), e os printfs são simplesmente uma forma de disciplina (é estúpido espalhá-los por todo o lado, então enquanto se pensa onde os colocar está-se a pensar no programa, além de que facilitam os testes automáticos).
É tudo uma questão de disciplina, algo que o debugger não potencia.
--
Carlos Rodrigues
|
| | | | eheheh o mais engraçado é que eu estava a falar do uso do gdb e do strace em projectos que não são teus :P
Tipo, aquela aplicação que estoira com um segfault, como aconteceu no Evolution com um email em HTML que a minha mulher recebeu e eu quis perceber qual seria o mal (GDB), ou uma aplicação que não arrancava porque dizia que não encontrava o ficheiro xpto (strace).
---
Este espaço pode ser seu... |
| | | | Normalmente nesses casos uso o strace ou o ltrace. Bom, sendo assim é capaz de dar mais de duas horas...
--
Carlos Rodrigues
|
| | | | | E se a tua plataforma não tiver printf? Como por exemplo, em sistemas embutidos, como é que seues a execução do programa? Acendes LED? Um debugger pode ser bom. No PC, concordo contigo e é geralmente mau, pois esconde muitas vezes código mal pensado. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | Bom, se consegues usar um debugger em cima de um programa a correr directamente no aparelho, porque é que não podes deitar printfs (ou algo assim) pelo mesmo caminho?
--
Carlos Rodrigues
|
| | | | apesar de não ser possível (ou não era possível, no último ano a coisa pode ter mudado), fazer debugging no Symbian com "printf's" era um br*che autentico... you don't want to go there
---
Este espaço pode ser seu... |
| | | | | | Podes fazer printf pelo jtag, e tens razão nisso, basta alterar a função _write. No entanto, quando fazes printf estás a inserir uma data de influências externas no programa. Isto é, ele já não é o mesmo. E além disso, podes não ter RAM para stack do printf. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | Tanto quanto sei, o interface JTAG não costuma ser acessivel ao código a correr no microprocessador. (e sim, eu estava a dar um exemplo de onde é possivel usar um debugger mas não é possivel fazer printfs).
|
| | | | | Podes fazer printf pelo JTAG (been there, done that, works awefully). Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | | Eu prefiro sempre pensar naquilo que era suposto estar a acontecer e não naquilo que efectivamente está a acontecer. Portanto eu prefiro gastar 20 minutos recostado na cadeira a pensar do que 20 minutos a seguir a execução do programa. Quando pensar não é suficiente, metem-se uns printfs em locais estratégicos. Um debugger serve para descobrir erros nos quais são dificeis de detectar à primeira vista. E porra um gajo não demora 20 minutos a ver a execução do programa. Se demora 20 minutos a descobrir no debugger então lendo o código demora muito mais. É para isso que serve o debugger -> para descobrir erros rápidamente e onde não para os solucionar. Muitas pessoas põe dois printfs para verem em que zona é que o código está a ter um comportamento que não é o esperado. Para quê usar printfs quando com o debugger descobre-se logo a linha e ainda se pode ver os estados das variaveis ao longo da execução. Mas melhor mesmo é usar muitos testes unitários para cada módulo/funcionalidade. Essa é uma das boas práticas da engenharia de software.
|
| | | | Achas estão completamente desapropriado os Debuggers todos bonitos que são implementados. Achas que a solução de fazer printf estratégicos é a melhor solução ....
ok .. se assim é .. não é possível discutir contigo, pois apesar de teres ferramentas de análise do teu carro, quando ele avaria perferes abrir o capõ e olhar para o motor e imaginar todos os processos e descobrir qual o errado..... parece bem.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | Estás nervoso pá :P eu não disse nada disso. A secção dos printf's é mais abaixo, com o CrLf.
---
Este espaço pode ser seu... |
| | | | Os debuggers são apropriados quando usados com peso e medida. Mas em 99% dos casos são usados por programadores com casos agudos de preguicite mental. O resultado é invariavelmente código mal feito. O debugger não serve para corrigir algoritmos, serve para os remendar. E é isso que sai no final, um monte de remendos a que chamam programa.
Daquilo que vejo, a utilização intensiva de debuggers anda de mãos dadas com funções gigantescas e com um combóio de parâmetros, ciclos for/while/for, variáveis de estado, casos especiais a granel e outros assassinatos que tais. É que quando estás a usar um debugger, a navegar no código passo a passo, a tentação de acrescentar um caso especial para resolver o problema é forte demais. Isto pode não acontecer sempre, mas já vi tanto disto que começo a duvidar.
ok .. se assim é .. não é possível discutir contigo, pois apesar de teres ferramentas de análise do teu carro, quando ele avaria perferes abrir o capõ e olhar para o motor e imaginar todos os processos e descobrir qual o errado..... parece bem.
Não é uma boa analogia, porque um carro não é algoritmico, é mecânico. Programar é algoritmico, fazer debugging é mecânico.
Mas pegando nisso, quantas vezes um mecânico de qualidade e com intuição não resolve os problemas muito mais rapidamente, e eficazmente, do que os que recorrem às máquinas de análise? Já vi isto ocorrer diversas vezes, posso dar-te um exemplo rápido (o mais flagrante):
O meu carro tinha uns problemas após o arranque (não é normal um carro ir-se abaixo em ponto morto, ou com a embraiagem toda em baixo) e o único tipo que conseguiu dar com o problema, foi lá porque "o seu carro tem um trabalhar esquisito". Ora eu tenho o carro à 12 anos, e até sou um gajo que gosta de inspeccionar o motor e tal (para aprender alguma coisa, o conhecimento não acaba na informática), e nao tinha dado por nada. Aliás, a diferença era tão diminuta que mais ninguém a detectou. Os outros fizeram testes, aumentaram a rotação mínima (o ralênti, ou lá como se escreve) e nada.
A intuição sobre os problemas é muito mais valiosa do que saber usar um debugger, e essa intuição só se ganha pensando.
--
Carlos Rodrigues
|
| | | | Esta mania de associar a falta de IDEs a falta de produtividade só tem uma explicação: não conhecem as ferramentas com que trabalham e têm medo de desenvolver de uma forma diferente.
Apesar já muito ter sido falado do assunto, vou deixar a minha opinião.... SIM .. o IDE é importante especialmente devido à sua estrita ligação à linguagem, por exemplo:
* Code-Completation - Os IDE que não tem uma ligação estrita coma linguagem e tem implementada esta deature, por vezes não completam o código todo, só classes implementadas e muitas vezes mal.
* Complilação - Muitos são meras peças de desenvolvimento e não se integram com o compilador, logo, não podemos com uma tecla iniciar a compilação e obter uma lista de erros no próprio IDE.
* Debugging - Este assunto já foi largamente falado nesta thread e o que acho é o segunte: o Debugging é importante, especialmente quando estamos a rever código desenvolvido por outros. Serve também para rapidamente detectarmos erros menores em objectos referenciados em camadas mais baixo nível.
Claro que estes pontos não te dizer nada, pois, perferes usar o VI (penso eu) para programar em tudo e como perferes .. todos tem que perferir e o VI é a melhor ferramenta de desenvolvimento que existe.
Se fosse, possivelmente outras tinham aparecido e tinham morrido, pois, todos continuavam a usar o VI.
É verdade, mas pensava que estávamos a falar de desenvolver em Mono + Linux, não de usar o Linux no desktop dos contabilistas e gestores...
Estamos a falar das razões que penso serem pela estratégia da Novell e pela minha análise, não tem haver só com o desenvolvimento, mas, para que um utilizador possa comprar uma versão do Software e consiga instalar tanto no Window$ como no Linux usando como plataforma de desenvolvmento desse produto .NET / Mono.
E qual é o problema de não ter SourceSafe em Linux? Se o problema for a integração em projectos que já o usam, podes sempre usar o SourceOffsite, que permite usar repositórios VSS a partir de várias plataformas.
E interliga-se com os IDEs da mesma forma que o IDE do VStudio interliga-se?
Bem, se calhar não, e é essa a decisão que as chefias da empresa não querem tomar, pois, ELES pensam que isso irá diminuir a produtividade.
Seja como for, as tuas razões são ainda insuficientes para convencer qualquer chefia de empresa a usar estas ferramentas, pois, o tempo que irias gastar a configurar, segundo as chefias, é tempo que deveria ser gasto para seres produtivo .. a produzires o que realmente a empresa necessita para ganhar dinheiro, pois, ele já tem uma solução para resolver os problemas de produtividade.
Estou de acordo contigo que muitas chefias tem é medo de arriscar, mas, não podemos fazer nada.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | Bom, já tive a opurtunidade de olhar para a integraçãodo SVN com o Vistual Studio 2003. Não gostei muito. Acabei a usar o TortoiseSVN.
Além do mais, merge-based SCCS e código gerado pelo UI designer tendem a dar-se mal. O VSS, sendo lock based, é menos produtivo mas também gera menos problemas destes.
|
| | | | Code-Completation - Os IDE que não tem uma ligação estrita coma linguagem e tem implementada esta deature, por vezes não completam o código todo, só classes implementadas e muitas vezes mal.
Code-Completion é uma funcionalidade irrelevante, é das primeiras coisas que desactivo quando tenho de usar um IDE que a tem. É mais ou menos o mesmo que o autocorrect do Office, só serve para atrapalhar. E é pior quando surge na forma daqueles popups irritantes, não gosto de ter a máquina sempre a dar-me palpites.
Completion é na shell e nada mais.
Complilação - Muitos são meras peças de desenvolvimento e não se integram com o compilador, logo, não podemos com uma tecla iniciar a compilação e obter uma lista de erros no próprio IDE.
Explica-me exactamente em que é que isto é crucial? Eu tenho uma xterm aberta para fazer a compilação e funciona perfeitamente. Não estou a ver.
Debugging - Este assunto já foi largamente falado nesta thread e o que acho é o segunte: o Debugging é importante, especialmente quando estamos a rever código desenvolvido por outros. Serve também para rapidamente detectarmos erros menores em objectos referenciados em camadas mais baixo nível.
Como já disse, eu raramente uso o debugger, mas sempre podes usar o gdb, ou o DDD se realmente não puderes passar sem uma ferramenta gráfica.
Claro que estes pontos não te dizer nada, pois, perferes usar o VI (penso eu) para programar em tudo e como perferes .. todos tem que perferir e o VI é a melhor ferramenta de desenvolvimento que existe.
Por acaso detesto o VI, mas usei o emacs durante bastante tempo. Agora uso o NEdit, ou o joe (que agora tem syntax highlighting, que é a única mariquice que realmente interessa). (For the record: o emacs tem code completion, compilação e debugging a partir da sua interface com integração com o código, integração com CVS e outros, e eu nunca usei nenhuma delas.)
Realmente, cada vez me chateia mais esta estirpe de programadores que mete IDEs para a veia. Que são incapazes de distinguir o fundamental do acessório, que acham que mariquices lhes aumentam a produtividade (quando esta é esmagadoramente definida pela capacidade de escrever código e raciocinar sobre o problema, e não por um botão "build" ou uma árvore de classes). Normalmente são os mesmos que demonstram níveis de ignorância medonhos em tudo o que não esteja intimamente relacionado com o trabalho em mãos. Que não sabem o que é NAT, ignoram o significado de exploit, não fazem puto de ideia porque é que um ciclo "for" pequeno corre desporporcionalmente mais rápido do que um ciclo "for" maior, etc, etc. Algo que eu ouço quase todos os dias de alunos de Engenharia Informática do 4º ou 5º anos. Quem enfie a carapuça quem achar que lhe serve.
Mas, o problema não é preferir usar IDEs, é não poder viver sem eles...
--
Carlos Rodrigues
|
| | | | Mas, o problema não é preferir usar IDEs, é não poder viver sem eles...
Tu vai é jogar no euro-milhões porque acabaste de acertar neste jackpot :P
---
Este espaço pode ser seu... |
| | | | | Muito honestamente, o teu problema é que pensas que o que resulta melhor para ti também resulta melhor para os outros ou então que os outros são todos incompetentes. Eu acho o auto-completion uma coisa boa em qualquer sitio, desde que decentemente implementado e te habitues a ele. Em particular, gosto quando se trata de programar porque facilita dar nomes decentes às coisas em vez de nomes minimalistas. Quanto à integração do compilador não me incomoda muito. Embora, da forma como eu dou erros a escrever, seja muito prático compilar com um clique e ir para a linha onde me esqueci de uma letra no identificador com outro. Debuggers, já falámos nisso há uns tempos. Eu gosto. Outras coisas boas nos IDEs: possibilidade de navegar pelo código através do diagrama de classes, de ir para a documentação de uma classe ou função com um clique. Se é verdade que muitos programadores passam demasiado tempo a bater nas telcas e pouco a pensar, também é verdade que há coisas que levam muito mais tempo a escrever que a pensar. Principalmente coisas triviais como o UI, que mesmo com UI-designers continuam a comer bastante tempo.
|
| | | | O que é importante compreender é que o acto de escrever está associado ao acto de pensar. Escrever ajuda a organizar as ideias porque impõe um ritmo mais lento, da mesma forma que falar o faz (não se diz que a melhor forma de aprender é ensinar por acaso). Não adianta escrever tudo muito rapidamente se depois vão ter de se enfiar no debugger durante horas.
--
Carlos Rodrigues
|
| | | | Para ti. Eu penso melhor sentado na borda de uma mesa com um bloco de notas na mão a fazer fluxograma s ou bonecada do género.
|
| | | | Não digo que não esteja completamente em desacordo contigo. Penso no entando que usar as novas ferramentas no que diz desenvolvimento não é assim tão mau como afirmas.
Penso que com a complexidade inerente aos projectos tanto o Code-Completention como o Debugger são importantes para podermos navegar em código desenvolvimento por 3ºs e não termos que re-escrever métodos que fazem o mesmo, mas, noutros objectos.
Seja como for, é de louvar a forma como te agarras à tua ideia que apesar de eu achar do seculo passado, é a tua e mereçe todo o meu respeito como espero que a minha posição (e de outros neste forum) sejam respeitadas por ti.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | Code-Completion é uma funcionalidade irrelevante Cheira-me que não tens muita experiência com projectos grandes, se não, não dizias isso. Teres um projecto que tem 300 classes com N métodos cada, é um pouco complicado sabê-los todos de cor. Digamos que andar à procura na documentação os nomes e parâmetros de métodos, não é tão produtivo como carregar num ponto e ter todos os métodos de um objecto mais uma descrição sucinta. Gostava de te ver a programar em Java/.NET sem intellisense. :-)
____________________
Pedro Santos :: psantos.net |
| | | | Bom, o maior projecto que fiz devia ter umas 12.000 linhas (em C), o que não é muito grande. Em Java acho que nunca passei das 5.000. Seja como for, não é preciso um projecto grande para usar muitas classes, a biblioteca de classes do Java já é grande o suficiente e a documentação HTML chega-me bem.
O meu problema é não suportar palpites da máquina e popups que só servem para me quebrar a concentração. Daí preferir de longe editores simples, onde eu me possa concentrar no código.
E isto é mesmo incrível, vocês não conseguem mesmo viver sem essas mariquices... Por acaso já pensaram que muitos projectos de grande dimensão são desenvolvidos nestes moldes? Que ferramentas julgam que usam os tipos do KDE, ou do kernel do Linux? Pelo que tenho visto (screenshots, palestras) não andam longe do que eu uso... Além do mais, como é que se programava antes de haver IDEs? E a percentagem de projectos que falham aumentou ou diminuiu deste então? E o tempo de desenvolvimento de cada projecto (a única coisa com real impacto aqui são os métodos de gestão de projectos e a existência de pataformas com toneladas de componentes reutilizáveis)?
--
Carlos Rodrigues
|
| | | | Existe uma diferença entre não conseguir viver sem os IDEs (editor de serviço: gEdit) e apreciar as pequenas mariquices dos IDEs.
|
| | | | gEdit?! Que é isso? Uma espécie de notepad com menos usabilidade??? ;-)))
---
Este espaço pode ser seu... |
| | | | É pequeno e funciona. Só sinto a falta de auto-identing (Python, Haskell).
|
| | | | gedit ... é tal e qual o vim, mas permite trabalhar em varios programas ao mesmo inteiro com syntax highlighting para uma data de linguagens.
Epah ... Existe o bluefish que é vocacionado para web programing, que tem akilo que o gedit n tem: uma arvore de navegação e manual para tirar as duvidas (embora só html, php, css e python).
É o que uso ... (mas vim tb é mto fixe de trabalhar) .. mas eu não sou programador !!!
Cumps-
Gass |
| | | | Está percebido que o desenvolvimento para ti é um hobby daí não sentires falta de nada...
Eu também para demonstrar conceitos ou fazer coisas pequenas só preciso de um editor, apenas concordo que uma coisa é utilizar muitas destas funcionalidades que visam dar produtividade ao programador ou ajudar o iniciado, e destas depender em absoluto, ou utilizar as que são ajuda eficaz à produtividade mas destas não depender.
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | Espero que entendas que cada um tem a sua forma de concentrar no código e deve ser repeitado.
Se os programadores do KDE, GNOME ou do Kernel Linux não Code-Completention ou se não usam um IDE Visual ou se não usam Debugger é de repeitar, pois, cada um usa as ferramentas que mais lhe derem jeito para atingirem os seus fins, agora, não me venham com essa conversa de: "Como eles não usam, ninguém deve usar, pois, tudo o resto é mau....."
Deixemos de falsos moralismos, vamos nos respeitar e deixar que cada um use as ferramentas que lhes dão meis jeito para o desenvolvimento.
A título de exemplo, hoje em dia estou a programar para a Xbox (XBMC) em Python e não não tenho forma de correr as minha aplicações num IDE bonito e retornar erros. Quando executo os meus scripts na XBox ou corre ou não corre .. e eu tenho que andar às voltas com erros pequenos às vezes como faltar uns : na definição de um ciclo. Se o proprio IDE me ajudasse e me desse esse erro, poupava alguns passos para o descobrir como: Gravar no disco local, copiar por FTP para a Xbox, executar o script e ver a janela de debug onde envio alguns prints com a informação do que vai acontecendo no script.
Seria bem diferente com debug local, mas, não é possivel.
Vivo bem sem um IDE, mas, entendo que com ele a vida de um programador é bem mais simples.
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | Code-Completion é uma funcionalidade irrelevante, é das primeiras coisas que desactivo quando tenho de usar um IDE que a tem.
e segundo a tua teoria todos o deviamos fazer? Eu gosto do Conde-Completention e não o quero desactivar e se puder irei ser um activista para que todos os IDEs o tenham.
Eu tenho uma xterm aberta para fazer a compilação e funciona perfeitamente
Ter o compilador e um validador de sintaxe no IDE é algo que considero importante, pois, nos permite que alguns dos erros mais simples sejam rapidamente detectados como falta de um ; nas linguagens baseadas no C, ou : no Python.
Este tipo de erros normalmente dá origem a outros erros que nada tem haver com o original o consome tempo à procura do erro real que o compilador detectou.
Uma vez na faculdade tinha um pequeno program em C num UNIX que não tinha mais de 20 linhas, mas, ao compilar dava cerca de 600 erros, tudo por causa de um ; (se bem me lembro).
Estes são os erros que obtemos por não ter Compilador e Validador de sintaxe no IDE.
Claro que se tu não gostas .. desactiva e usa a janela de Xterm na mesma, mas, não quer dizer que todos o tenhamos que fazer.
Poder de escolha e liberdade é bonito e não só na hora de escolher se o Software é OpenSource ou não, mas, também ,as ferramentas que usamos.
Como já disse, eu raramente uso o debugger (...)
e nem imaginas como fico contente por saber que alguém tem a capacidade inapta de não o usar, pois, passamos mais de 70% do tempo de desenvolvimento a corrigir erros.
Quando temos um conhecimento alargado da linguagem raramente fazemos Debug, pois, a análise esta estritamente ligada ao desenvolvimneto e raramente damos erros.
Houve uma linguagem que eu tinha esse nível e gostava de dizer às pessoas que gastava menos de 30% do meu tempo em Debug. Praticamente tudo o que escrevia estava certo.
Mas, o problema não é preferir usar IDEs, é não poder viver sem eles...
Eu sei viver sem ele ... mas que eles nos trazem facilidades .. isso é indiscutivel
(())
Esqueleto
------------------------------ Visit me in: http://wiki.online-na.net |
| | | | Migração não é o termo correcto: implica cortar com a plataforma/país/whatever anterior e substitui-lo por algo novo.
O caso aqui é extender o suporte da plataforma do Evolution. Parece-me uma excelente medida para preparar uma migração a larga escala, e essa sim, definitiva, de plataforma, se não vejamos: numa dada empresa, todos os utilizadores migraram para Evolution/(Thunderbird+Sunbird), OpenOffice.org, etc.. Se alterarem a plataforma de Windows para Linux, a diferença que irão efectivamente notar será quase nula, pois o trabalho que realizam, pelo menos neste âmbito, será rigorosamente igual.
Paradoxo do ano: Microsoft Works!
Dominus vobiscum |
| | | | | | sim ... realmente pode ser uma boa opção.
Não sei se se lembram, mas a novell tem uma má relação com a ms. E duvido que eles se esqueçam disso assim tão cedo (basicamente a ms começou a fazer concorrência à sua parceira novell, bem como deixando de suportar convenientemente os seus serviços)
Portanto ... tudo o k vier da novell será pró linux ou pró whatever.
Eles criaram o novell desktop, que segundo muita gente é mesmo um SO de desktop profissional ( aka que tem garantia e selo de funcionar como deve ser e ter tudo integrado) e disseram que era só um primeiro cheirinho, que não queriam fazer concorrência a ninguém ... ainda.
Espero que continuem e apresentem soluções melhores que a concorrência e que a propria concorrência entre distribuições (suse/novell, red hat , mandrake) se comece a sentir e que isso fundamente melhor a utilização de linux e opensource.
Cumps-
Gass |
| | | | Aperceberam-se que os seus produtos, tal como os da mozilla, têm qualidade para vingarem em algo mais do que uma plataforma que assassina a produtividade (sim, Linux).
--
O Trolha do Gildot
"There's a difference between a pretentious musical wank and a funky bassline" - Jaco Pastorius |
| | | + ou - (Pontos:3, Interessante) |
| | Bom, o port do Evolution para o Windows pode ter as suas vantagens, pelo menos permite livrar as pessoas da obrigação de usar o Outlook...
Mas acho que alguém podia também pegar no Connector e criar uma extensão para o Thunderbird. Por enquanto permitia ao Thunderbird falar com servidores exchange, e mais tarde poderia fazer algo mais juntamente com o Sunbird/Calendar.
No entanto... acho que isto vai trazer especiais benefícios ao GTK em Windows, porque eles vão ter de o melhorar em termos de aspecto e integração com o resto do ambiente.
Talvez assim o PyGTK se torne o toolkit multiplataforma de eleição para Python, e nos possamos livrar do feio Tkinter ou do wxPython, que em unix tem umas dependências gigantescas. Se bem que para isso também teria de funcionar nativamente em Mac...
--
Carlos Rodrigues
|
| |
|
