Padrão de pacotes no linux é INDISPENSÁVEL!!! junte-se a essa revolução !!

[Piras]

pois se fosse para usar o autopackage como padrão eu não estaria aqui neste tópico,pois se o autopackage fosse integrado ao sistema nativo (no caso do ubuntu o apt) não teria como gerar problemas de dependências repetidas (só so você acha que os sistemas nativos são problemáticos....),e ai que necessita a presença dos desenvolvedores das distribuições

A simples integração ao sistema nativo não resolveria o problema. Aqui não se trata de ser o "sistema problemático" ou não. É na compatibilidade entre sistemas distintos que reside o problema. Quanto maior for a quantidade de sistemas que o autopackage ou qualquer outra alternativa quiser atender, maior será o problema de compatibilidades e redundâncias.

Enfim, a raiz do problema não está no programa que faz o gerenciamento de pacotes, mas nas diferenças que existem entre os diferentes sistemas. Um kernel de hoje pode admitir funcionalidades que não existiam num kernel de doze meses atrás. Assim, alguns programas ou bibliotecas atualizados não funcionarão num sistema que emprega um kernel mais antigo. O autopackage não conseguiria resolver o problema. E mesmo um outro sistema, mais sofisticado, como Pacman, RPM ou DEB, teria dificuldades em resolver o problema se este não se resumisse a ausência de dependências, mas a incompatibilidade entre elas (quem já combinou diferentes ramos do Debian [estável, testing e untable], por exemplo, conhece muito bem a questão).

Como eu disse anteriormente, mesmo o Windows, cujo universo de programas e bibliotecas é muito menos variado que o nosso, tem enorme dificuldades em tornar compatíveis suas diferentes versões. Tanto que praticamente desistiu de fazê-lo com o Vista. Pois bem, a dificuldade de tornar compatíveis o Ubuntu e o Debian Etch ou a Arch e o Slackware não é muito diferente.

Assim, na minha opinião, padronizar o gerenciamento de pacotes no Linux ao nível que se propõe aqui (tornando possível a instalação do mesmo pacote em várias distribuições) exigiria forçosamente reduzir de modo drástico a diversidade do mundo Linux, como ela se apresenta hoje em dia. E eu acho esta premissa tão pouco possível quanto desejável.

[livio]

Eu não sou expert, mas acho que é realmente necesária a criação de um padrão para o linux.

Vejam só: já algum tempo que distribuições como Kurumin e Ubuntu vem trabalhando para tornar o Linux um sistema mais acessível para usuários que nunca viram uma linha de comando a não ser em quake e cs. Com isso, o linux tem se popularizado e ganhado muitos adeptos pelo mundo afora, fato que pode ser comprovado pelas recentes atitudes da Microsoft.

Convenhamos também que o número de distribuições vem crescendo, existindo mais de uma centena de distros baseadas apenas em Debian, sem contar com Red Hat, Suse, Slackware.

Com a recente popularização do Linux, o ritmo de desenvolvimento das distros vem crescendo tambem, algumas adotando empacotamentos e gerenciamento de pacotes específicos, nomes de arquivos de sistema podem ser diferentes, enfim, cada uma adotando aquilo que lhe parece melhor no momento e, com isso, poderá ocorrer que em breve a única coisa em comum será o kernel, que precisará ser compilado para cada distro.

Com isso, torna-se muito difícil para uma empresa de software criar programas para Linux, uma vez que não existe um padrão que permita que seus programas sejam compatíveis com todas as distribuições.

Sei que estou exagerando, mas se não cortar o problema enquanto for cedo, mais tarde será mais difícil e custoso para as comunidades e mantendedores.

Outro fator a ser analisado é que o Linux tem bem mais programadores que a Microsoft e a Apple, só que estão todos espalhados pelo mundo. Agora imagine se de alguma forma conseguíssemos trabalhar todos em conjunto, pensem na dor de cabeça que isso seria para a Microsoft.

Lembrem do conto do beija-flor no incêndio da floresta, quando todos os animais corriam e o beija-flor voltava com uma gota de água no bico. Quando outro animal lhe perguntou se ele achava que iria apagar o incêndio, ele respondeu que não, mas que fazia apenas sua parte.

Enforços individuais podem obter bons resultados, mas quando nos juntarmos, seremos como o incrível Mega-Zord, que sempre derrota o monstro.

Só uma curiosidade: pinguins que andam juntos não são devorados pelas focas.

http://www.blogdochagas.com/imagens/pinguim_guerra.jpg

Agora olhem essa imagem e tentem se inspirar.

[s4suk3]

Concordo com o Piras.
A questão principal, além da incompatibilidade de pacotes, de dependências, de bibliotecas, algo que acontece bastante quando se misturam pacotes atuais com distros antigas(antigas, mesmo se comparar o Arch ao Ubuntu, nem irei usar o exemplo do Debian, já teremos MUITAS dependências faltando, incompatíveis, com conflitos ou simplesmente ultrapassadas por versões mais novas).

Além do que, nem todo mundo gosta do APT, ou do urmpi, ou do yast2.
Definir um padrão e manter os gerenciadores individuais de cada distro somente daria ainda mais problema, pois seriam usadas diferentes ferramentas para remover pacotes(além de outras operações), o que aumentaria ainda mais o trabalho do usuário pra remover o mesmo.

E outra coisa, existem certos sistemas de pacotes que são motivo de destaque para suas distros portadoras, como o Foresight Linux e o Arch Linux, com seu conary e pacman, respectivamente. Se houver uma padronização, isso irá se perder, e elas serão apenas distros comuns.

E cadê a liberdade de escolha? :]

[Komodor]

A simples integração ao sistema nativo não resolveria o problema. Aqui não se trata de ser o "sistema problemático" ou não. É na compatibilidade entre sistemas distintos que reside o problema. Quanto maior for a quantidade de sistemas que o autopackage ou qualquer outra alternativa quiser atender, maior será o problema de compatibilidades e redundâncias.

Enfim, a raiz do problema não está no programa que faz o gerenciamento de pacotes, mas nas diferenças que existem entre os diferentes sistemas. Um kernel de hoje pode admitir funcionalidades que não existiam num kernel de doze meses atrás. Assim, alguns programas ou bibliotecas atualizados não funcionarão num sistema que emprega um kernel mais antigo. O autopackage não conseguiria resolver o problema. E mesmo um outro sistema, mais sofisticado, como Pacman, RPM ou DEB, teria dificuldades em resolver o problema se este não se resumisse a ausência de dependências, mas a incompatibilidade entre elas (quem já combinou diferentes ramos do Debian [estável, testing e untable], por exemplo, conhece muito bem a questão).

é claro,mas o programador tem que ter isso em mente. como hoje em dia que eles não usam as novidades dos kernel's para que uma quantidade maior de distribuições possam usar.

o formato não tem como objetivo ser perfeito,mas amenizar ao máximo os problemas.como no caso dos deb,rpm,etc. esses mesmo que tu pegue 2 distribuições com os mesmos pacotes,tudo igual,corre um grande risco de não funcionar,não por causa de incompatibilidade mas sim que esses pacotes não foram feitos para serem multi-distro

veja por exemplo esse (.bin) e (.run),que são os mais usados por programas fechados,eles tem o objetivo de atingir o máximo de distribuições possíveis,primeira coisa que eles fazem é compilar para versões anteriores para que funcione em quase todas as distribuições atuais,depois eles irão ter que ver em quais lugares salvar (pois muitas distros modificam pastas do sistema),qual nome executar da lib executar,e ai por diante.

a questão de incompatibilidade por usar o kernel mais novo ou tal parte mais nova é coisa que o programador tem que ter em mente,pois programar sem ter isso em mente,o programador tem que ser muito novato ou muito burro!é coisas que eles já fazem hoje em dia,não haveria diferenças em relação a isso.

e se for problemas de algum programa que precisa de alguma versão mais nova ou que não esta instalada chama o gerenciador padrão do sistema (como o apt)

Como eu disse anteriormente, mesmo o Windows, cujo universo de programas e bibliotecas é muito menos variado que o nosso, tem enorme dificuldades em tornar compatíveis suas diferentes versões. Tanto que praticamente desistiu de fazê-lo com o Vista. Pois bem, a dificuldade de tornar compatíveis o Ubuntu e o Debian Etch ou a Arch e o Slackware não é muito diferente.

o windows é um pouco diferente. o vista ele não se importou em fazer funcionar as outras versões apostando no seu monopólio.fazendo com que o pessoal migre para o sistema novo,pois os novos programas serão feitos para vista e as pessoas serão obrigadas a migrar junto.

não é só uma questão de compatibilidade,o vista veio do kernel do xp modificado,ou seja o kernel já não é só uma melhoria (que ocorre com o linux,que por exemplo o kernel 2.6 foi lançado e depois ficam muito tempo no 2.6.2 e ai por diante).mas a questão é que pelomenos 90% das distribuições atuais já utilizam o kernel 2.6,você tera comparações a nivel de vista vs xp,se comparar certos recursos do 2.6 com o 2.2 por exemplo,mas tem programas que abrangem desde o kernel 2.0 ao kernel 2.6 atual.

nós não modificamos o kernel a esse ponto,se você der um molhada nos jogos vendidos para linux,como Doom 3,quake 4,UT 2004,e assim vai,veras que a maioria deles funcionam do kernel 2.4 em diante,
o kernel 2.4 é muito antigo,mas até hoje ele é suportado ai prova que nosso caso é muito diferente

Assim, na minha opinião, padronizar o gerenciamento de pacotes no Linux ao nível que se propõe aqui (tornando possível a instalação do mesmo pacote em várias distribuições) exigiria forçosamente reduzir de modo drástico a diversidade do mundo Linux, como ela se apresenta hoje em dia. E eu acho esta premissa tão pouco possível quanto desejável.

nada que não é possivel,pois como eu expliquei no 1º post, o programador ele tem que saber que não podera usar os ultimos requisitos do sistema,como hoje eles fazem,veja que até programas como UT2004 que tem requisitos de kernel 2.4 em diante.. até mesmo o cedega que roda os jogos mais pesados da plataforma windows,ele suporta o kernel 2.4 em diante.

a incompatibilidade é responsabilidade do programador,se ele quiser ele pode realmente fazer algo assim,mas ele terá que ser muito burro.

hoje esse pacotes alem deses pacotes como deb,e rpm não funcionarem em distribuições que tem os mesmo requisitos,o mesmo sistema,por ser distribuição diferente já dara problema.

mais do que qualquer coisa esses deb,rpm não conseguem nem fazer isso,que é rodar em distribuições com sistemas iguais,alem de não estar nada padronizado,de o programador não ter acesso a uma interface gráfica que ele pode controlar,pedir senha,serial,etc.não pode perguntar o local para instalar etc.

[vinicius_aleao]

Bom, gente, é o seguinte: por tudo o que eu vi das discussões de vocês, talvez o melhor seja um meio-termo. Mesmo considerando-se a impossibilidade parcial de se ter um pacote padrão, por todos os problemas apontados pelos colegas, ainda assim eu defendo que deveria haver uma integração maior entre as várias distros para facilitar a vida das empresas que porventura desejem lançar programas para linux. Se não é possível um padrão, também não acredito que não se possa fazer nada para se aumentar as chances de um pacote "padrão" hipotético rodar adequadamente em um maior número de sistemas, desde que as distros unifiquem, pelo menos na medida do possível, o tratamento para este pacote. Acho que algo pode ser feito, sim.

[Mythus]

Bom, gente, é o seguinte: por tudo o que eu vi das discussões de vocês, talvez o melhor seja um meio-termo.

Meio termo é o que hoje está. Antes de ter uma discussão sobre um "empacotamento universal", é necessário que exista uma árvore universal de diretórios no linux e isso tem sido uma luta da LSB, que inclusive apontou o RPM (desde 2003) como um padrão que deveria ser universal.

Temos muitas distros que respeitam as normas gerais da LSB, mas não existe uma árvore definitiva e, conseqüentemente, ainda que houvesse um pacote universal, ele estaria prejudicado.

A liberdade tem seu preço.

[Piras]

Bom, gente, é o seguinte: por tudo o que eu vi das discussões de vocês, talvez o melhor seja um meio-termo.

Meio termo é o que hoje está. Antes de ter uma discussão sobre um "empacotamento universal", é necessário que exista uma árvore universal de diretórios no linux e isso tem sido uma luta da LSB, que inclusive apontou o RPM (desde 2003) como um padrão que deveria ser universal.

Temos muitas distros que respeitam as normas gerais da LSB, mas não existe uma árvore definitiva e, conseqüentemente, ainda que houvesse um pacote universal, ele estaria prejudicado.

A liberdade tem seu preço.

Concordo em número, gênero e grau, especialmente com a última frase. Seria ótimo de fato se todas as distros adotassem uma árvore idêntica. Mas veja o caso, por exemplo, da Gobolinux, uma distribuição de cuja criação e desenvolvimento participam muitos brasileiros. Ela adota uma árvore bastante diferente (mais próxima a do Mac OS do que do Linux) e - mesmo assim - é um excelente projeto. Aliás, seus recipes, que são scripts para compilação de bibliotecas e programas, funcionam de forma muito similar ao autopackage.
Há uma diversidade no mundo Linux que eu detestaria sacrificar em troca dos benefícios do maior conforto. Até pelo fato de que, no meio termo em que vivemos hoje, há muitas distros bastante fáceis de usar, como é o caso do nosso Ubuntu, do PCLinuxOS, do openSuse, etc. E o modo como funciona o gerenciamento de pacotes nestas distros é hoje tão semelhante (até as interfaces gráficas dos respectivos gerenciadores de pacotes são cada vez mais parecidas...) que, em pouco tempo, ao se conhecer uma, se conhece todos.

[zoroastro]

"Liberdade de Escolha prevalece, na minha opinião."
amigo você chegou a ler todo o artigo? a padronização não faz com que deixem de usar os outros pacotes!! mas cria um em que o programador possa ter certeza que irá funcionar em qualquer distro sem bugs (pois esse pacote irá ser feito pelas distros,ai que esta o funcionamento sem bug).

é.... eu havia argumentado igualmente ao s4suk3, e não li o artigo... tirei conclusões precipidadas...


quando der, irei ler o artigo

[Komodor]

Concordo em número, gênero e grau, especialmente com a última frase. Seria ótimo de fato se todas as distros adotassem uma árvore idêntica. Mas veja o caso, por exemplo, da Gobolinux, uma distribuição de cuja criação e desenvolvimento participam muitos brasileiros. Ela adota uma árvore bastante diferente (mais próxima a do Mac OS do que do Linux) e - mesmo assim - é um excelente projeto. Aliás, seus recipes, que são scripts para compilação de bibliotecas e programas, funcionam de forma muito similar ao autopackage.
Há uma diversidade no mundo Linux que eu detestaria sacrificar em troca dos benefícios do maior conforto. Até pelo fato de que, no meio termo em que vivemos hoje, há muitas distros bastante fáceis de usar, como é o caso do nosso Ubuntu, do PCLinuxOS, do openSuse, etc. E o modo como funciona o gerenciamento de pacotes nestas distros é hoje tão semelhante (até as interfaces gráficas dos respectivos gerenciadores de pacotes são cada vez mais parecidas...) que, em pouco tempo, ao se conhecer uma, se conhece todos.

em nem um ponto deste tópico foi dito que os pacotes como deb e rpm são complicados de se lidar. esses pacotes para mim pelomenos é extremamente facil,e concordo que os deb rpm e outros tem aparências muito parecidas

mas o principal fator deste padrão que tentamos estipular é a dificuldade que os desenvolvedores passam (e não os usuários,veja bem isso)

pois nos casos dos projetos fechados,a maioria usa (.run) e (.bin),não todos mas a maioria.porque eles fazem isso? bem pelo fato principal do tópico,de não ter que ficar compilando para centenas de distribuições separadas.todos sabem que os pacotes nativos sempre tem ferramentas que o usuário achara muito fácil de se utilizar,mas para ficar criando pacotes para todos não é fácil.

como funciona por exemplo esses (.run) que a maioria dos projetos fechados criam? bem são scripts,que analisam qual tua distribuição,caso seja aquelas que eles preveram terá os famosos "if" que ele irá fazer certo,caso não seja ou ele irá lhe perguntar aonde esta as libs,aonde esta isso,etc. (como no caso do vmware workstation 6).e ai cade a facilidade?? tem alguns programas por exemplo como o IBM Lotus Symphony. que eles criaram manualmente todo uma interface gráfica em tcl/tk. que te pergunta aonde quer instalar,se quer instalar todos os componentes do suite office,etc.

no caso desse symphony por exemplo,ele vem nesse (.run) ou (.bin),não me recordo ao certo.você precisa primeira coisa dar permissão de executar ele como programa,depois você terá que ir ao terminal para executar ele (mesmo que esse especifico abra sem ser pelo terminal,pelomenos 90% dos outros (.run) e (.bin) geralmente precisam de alguma coisa a ser feita em modo texto antes,como aceitar alguma licença etc...

a questão é que os (.deb) (.rpm) etc,não tem como substituir por vários fatores,a maioria dessas empresas fortes de código fechado não irão utilizar,os motivos é aqueles que eu sempre cito que o rpm deb,etc não são capazes de fazer.
vou citar alguns:
1- você não pode pedir o serial do programa antes de instalar.
2- você não pode deixar o programa perguntar quais componentes ele deve instalar.vamos a um exemplo do IBM Lotus Symphony,ele é um suite office,você quem sabe gostaria de instalar só o editor de documentos,infelizmente isso não é possível com o deb,rpm,etc..
3- perguntar aonde salvar. quem sabe você quer deixar seu sistema mais organizado e salvar tais programas em certos lugares específicos.ou até mesmo porque em tal parte não tem o espaço suficiente e você não pode gravar lá,mas isso não é possível com deb,rpm,etc....
4- perguntas sobre alguma outra coisa,como salvar ícones,ou até mesmo verificar atualização direto do site sem a utilização de um repositório,pois as empresas não criam repositórios. infelizmente isso não é possível com deb,rpm,etc
5- você quer quem sabe fazer alguma coisa diferente,fazer uma outra parte de interface gráfica,perguntar alguma outra coisa,mostrar alguns telas do programa etc,infelizmente isso não é possível com deb,rpm,etc. pois o deb você não tem direito de pedir alguma coisa ao usuário,no máximo mostrar a licença

e assim por diante

você sempre faz comparações com deb,rpm,o porem é que essas ferramentas eles não irão utilizar são pouquíssimas empresas que os utilizam.por aqueles motivos que apresentei e vários outros fatores.
o que eles utilizam bastante é os (.run) e (.bin) que eles tem que desenvolver todo um instalar em tcl/tk (que tem a aparência tenebrosa),eles tem que prever tudo,tem que pensar em tudo o que as distribuições irão diferenciar nos projetos.e isso é algo extremamente complicado.e saberá que nunca irá ficar perfeito pois não tem padrão algum

Há uma diversidade no mundo Linux que eu detestaria sacrificar em troca dos benefícios do maior conforto.

eu não chamaria de conforto,eu chamaria de compatibilidade,que eu terei certeza que o software irá funcionar na distribuição.ou terei que usar alguma outra distribuição para que funcione perfeitamente o software

me diga qual as diversidades que você se refere quando diz que necessita "sacrifica-las"

[vinicius_aleao]

De fato, eu gostaria de ter liberdade na escolha de diretório de instalação de programas. Digo isso porque tenho pouco espaço no HD e gostaria de deixar programas grandes numa partição separada, e não na partição do sistema. Nesse caso, não se pode falar que eu tenho liberdade. Será que não seria o caso de se ter um "padrão" (as aspas são por compreender que um padrão de fato pode ser ruim, como os colegas têm apontado) para que possamos ter esse tipo de possibilidade?

[s4suk3]

De fato, eu gostaria de ter liberdade na escolha de diretório de instalação de programas. Digo isso porque tenho pouco espaço no HD e gostaria de deixar programas grandes numa partição separada, e não na partição do sistema. Nesse caso, não se pode falar que eu tenho liberdade. Será que não seria o caso de se ter um "padrão" (as aspas são por compreender que um padrão de fato pode ser ruim, como os colegas têm apontado) para que possamos ter esse tipo de possibilidade?

Sem querer fazer propaganda, mas já fazendo: o Pacman permite isso, editando os PKGBUILDs. Mas, nesse caso, o pacote precisa ser compilado direto da source. mãs... eu creio que dê também para realizar as instalações de programas dentro de um chroot, mas não tá comprovado =P

[Piras]

A imensa maioria dos usuários do Linux está concentrada em quatro ou cinco distribuições, não mais do que isto. Quem quiser tornar disponível um programa qualquer para mais de 80% dos usuários não precisará compilar mais do que dois DEB, dois ou três RPM, um TGZ e ponto final. E boa parte dos projetos abertos que eu conheço faz isto. Os aplicativos proprietários são outra história, mas boa parte deles ignora o Linux por motivos puramente comerciais e não pela ausência de um pacote padrão.

Ter um pacote padrão poderia até mesmo ter a sua utilidade, mas como se fala neste tópico de indispensável eu discordo e até agora não li nada que me convencesse do contrário.

[Komodor]

De fato, eu gostaria de ter liberdade na escolha de diretório de instalação de programas. Digo isso porque tenho pouco espaço no HD e gostaria de deixar programas grandes numa partição separada, e não na partição do sistema. Nesse caso, não se pode falar que eu tenho liberdade. Será que não seria o caso de se ter um "padrão" (as aspas são por compreender que um padrão de fato pode ser ruim, como os colegas têm apontado) para que possamos ter esse tipo de possibilidade?

para podermos ter programas que perguntam aonde instalar uma coisa já é necessária,não utilizar deb,rpm,etc pois esses não tem como gerar esta pergunta ao usuário,tem que ser estabelecido ao criar o pacote.

este é um dos fatores que a maioria das empresas grande que cria softwares fechados não utilizam os pacotes como deb e rpm.mas na grande maioria os (.run) (.bin),etc

vou citar aqui alguns dos programas que usam estes formatos,alguns foram criados interface gráfica outros não(dependendo ir ao terminal).
IBM Lotus Symphony  [suite office baseado no openoffice,criado pela IBM]
Vmware Workstation6 [criar,rodar,editar maquinas virtuais]
Unreal Tournament 2004 [ jogo de tiro em primeira pessoa,jogo famoso]

deixando bem claro que existe empresas que fazem os programas em pacotes (.deb) (.rpm),só que é minoria das empresas de código fechado.só que por esses pacotes serem limitados a diversas coisas que não se pode fazer (que eu citei na resposta anterior)

o padrão,ele iria substituir na maioria dos casos as empresas que usam os (.run) e os (.bin),pois as empresas que não se importam em criar diversos pacotes para diversas distros e não levam em conta o fator dos (.deb) e (.rpm) não terem certos recursos,esses não irão mudar,e tambem não há necessidade para eles

o que muitas pessoas pensam é que com o padrão todos são obrigados a usar,sendo que na verdade ninguém seria obrigado a absolutamente nada.só que o padrão criar um pacote que o programador teria certeza que não teria diferenças entre distribuições (as que respeitassem o padrão é claro)

a integração com sistema nativo como o apt,não traria problema e iria ajudar muito a distribuição,faria com que a distribuição não necessite mudar a base do sistema,usando o gerenciador que a distribuição confia e gosta.

[Komodor]

A imensa maioria dos usuários do Linux está concentrada em quatro ou cinco distribuições, não mais do que isto. Quem quiser tornar disponível um programa qualquer para mais de 80% dos usuários não precisará compilar mais do que dois DEB, dois ou três RPM, um TGZ e ponto final. E boa parte dos projetos abertos que eu conheço faz isto. Os aplicativos proprietários são outra história, mas boa parte deles ignora o Linux por motivos puramente comerciais e não pela ausência de um pacote padrão.

Ter um pacote padrão poderia até mesmo ter a sua utilidade, mas como se fala neste tópico de indispensável eu discordo e até agora não li nada que me convencesse do contrário.

você esta querendo dizer que deveria fazer para 4 distribuições e mandar o resto que se fod*?

me diga então o porque do fato que você sempre se faz que não lê,diga-me aqueles fatores que já repeti varias vezes,que é os fatores que os (.deb) e (.rpm) não disponibilizam (2 repostas minhas antes desta)
me explique porque então os programa de código fechado na maioria não utilizam estes pacotes (deb,rpm etc) e sim os (.run) e (.bin).

você sempre discorda mas parece que certos argumentos tu sempre faz questão de não ler,interessante....

[vinicius_aleao]

Calma, Komodor. Eu estou sentindo, e não é de agora, uma certa hostilidade nos seus posts. Eu tenho tido muita consideração pelos seus argumentos, acho que são pertinentes, mas também acho que o restante do pessoal tem a sua razão também. Foi por isso que eu falei num meio termo antes. Não há razão pra desavença.

Agora, acho que você tem que rebater dizendo naturalmente que não concorda e mostrando seus argumentos, porque tem hora que, ao meu ver, você insinua que o pessoal está com má vontade ou sei lá o quê. Por favor -- até porque eu estou também me sentindo um pouco o pivô dessa discussão -- seja um pouco mais moderado.

E muito obrigado a todos pelos esclarecimentos, vocês me têm feito aprender bastante