Fórum Ubuntu Linux - PT
Espaço da Comunidade => Café com Ubuntu => Tópico iniciado por: Xanio RetangulosS em 20 de Setembro de 2007, 19:31
-
Padrão de pacotes no linux.
é algo extremamente importante no tempo de hoje,porem se não nos juntarmos não conseguiremos NADA. esse será um avanço muito grande no linux,porem precisa de seu apoio!
o tópico de referencia é esse:
http://uplink-for-ever.blogspot.com/2007/09/softwares-de-cdigo-fechadoiro-algum-dia.html
por favor leia todo o texto antes de postar. obrigado
coloque em sua assinatura:
Padrão de Pacotes no linux é INDISPENSÁVEL! junte-se a nós
http://ubuntuforum-br.org/index.php/topic,25549.0.html
o crescimento do linux depende deste padrão,apóie você também!
a pedido do Komodor reeditei o tópico
-
pensei que fosse só eu que leia esse blog :P
acabei de ler,e também apoio TOTALMENTE o padrão de pacotes no linux
obs: só achei que o assunto do tópico ficou meio confuso,deveria mudar o título para uma melhor compreensão
### EDIT ###
ei xanios,acrescente isso ao seu tópico:
coloque em sua assinatura:
Padrão de Pacotes no linux é INDISPENSÁVEL! junte-se a nós
http://ubuntuforum-br.org/index.php/topic,25549.0.html
o crescimento do linux depende deste padrão,apóie você também!
-
Dou meu total e irrestrito apoio!
-
também dou meu apoio, mesmo pq pro linux continuar crescendo, isso é de fundamental importancia..
abraços a todos...
-
Ola
Eu também apoio um padrão dos pacotes, em praticamente todos os foruns que vou que abordam o Open Source praticamente todos falam deste assunto de não haver um padrão e eu acho indispensável para o OS poder crescer e ate mesmo simplificar.
Cumps.
-
Mas... o RPM já não seria um padrão? de uma forma ou de outra, todas as principais distribuições grandes o suportam, inclusive as baseadas no Debian. Ok, eu sei que não é recomendada a utilização, pois pode gerar inconsistências, mas funcionar funciona.
-
Mas... o RPM já não seria um padrão? de uma forma ou de outra, todas as principais distribuições grandes o suportam, inclusive as baseadas no Debian. Ok, eu sei que não é recomendada a utilização, pois pode gerar inconsistências, mas funcionar funciona.
o RPM da redhat, o DEB do debian,o TGZ do slack,e assim por diante.
esses pacotes não tem um padrão,eles tem suas regras,são pacotes como arquivos pré-compilados.
mas que muda de distribuição para distribuição.
tanto é que não utilizamos os .deb do debian,e sim o deb do ubuntu.
é para isso que precisa a padronização,os programas podem até funcionar do debian pro ubuntu,mas ninguém lhe dará garantia.e muito menos irão te recomendar.é no caso da sorte,provavelmente o programa funcionara,mas fara alguma coisa errada,como por exemplo colocar arquivos em lugar errado,chamar tal programa que não se encontra ali.
em caso de um particionador ou algum programa que faça uma edição no kernel do linux você teria coragem de instalar um programa de outra distribuição? sendo que ninguém irá lhe certifica que este programa não irá lhe corrompe seu sistema?
o padrão é exatamente para isso para certificar o funcionamento a todas as distribuições que seguem aqueles padrões.esses problemas de incompatibilidade entre distribuições iriam desaparecer,pois viver no "tenta se não funcionar o máximo que pode acontecer é corromper seu sistema" não é legal
abraços
-
O formato de pacotes definido pelo Linux Standard Base é o RPM. Mas duvido que as distros Debian e Debian like mudem para esse formato. O pessoal que faz tanta questão de um padrão de pacotes deveria então mudar para uma distro que adote o formato RPM, já que esse é o padrão do Linux.
http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html (http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html)
-
O formato de pacotes definido pelo Linux Standard Base é o RPM. Mas duvido que as distros Debian e Debian like mudem para esse formato. O pessoal que faz tanta questão de um padrão de pacotes deveria então mudar para uma distro que adote o formato RPM, já que esse é o padrão do Linux.
http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html (http://refspecs.linux-foundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html)
como se o RPM resolvesse os sintomas descritos naquele post do blog...
mesmo que use RPM,você criara uma versão para Red Hat,outra para fedora,outra para suse,etc.
o RPM não é mais do que um pacote que guarda os arquivos pré-compilados com destino especifico, que no máximo verifica as dependências ,verifica a versão,e algumas coisas assim.(quase igual ao DEB) e pronto
nele não é estabelecido nem um local especifico para a instalação de pacotes,poderia no formato base definir algo como uma variável do local correto das libs,o programa redirecionaria para a variável e ai o formato iria fazer instalar corretamente
RPM é um pacote que de padrões não tem nada.pois se tivesse padrões para multi-distro você não teria problema de instalar um programa em RPM do suse no fedora,mas as coisas não são bem assim,você pode até fazer funcionar..... mas.....
em nem um argumento o RPM solucionaria esse caso que no blog explica,porque se fosse só por ser padrão não teria a necessidade.....
[pedido] pessoal por favor LEIAM todo o artigo antes de postar... [/pedido]
-
Komodor, eu não disse que o RPM resolveria todos os problemas. Mas se nem mesmo o formato RPM, que é o padrão do Linux, é adotado por distros populares como o Debian e o Ubuntu, o que esperar do resto? Seria necessário que primeiro se adotasse esse formato padrão, para depois procurar construir pacotes RPM que funcionassem em qualquer distro.
-
O ideal seria que as distros top se reunissem e traçassem os parâmetros de como seria um pacote ideal, que funcionaria em qualquer distro sem muita gambiarra. Feito isso, fariam um protótipo e testariam o suporte dele em suas distros. Tudo ok? Então manda para a ISO transformar em um padrão e as próprias distros passam a usar esse padrão, mesmo que não deixem de usar seus próprios formatos de pacotes. A partir daí, teríamos um Linux mais padronizado, mesmo que as distros insistam em fazer suas próprias personalizações.
Existe o autopackage, que poderia fazer essa função, mas é preciso ver se ele realmente funciona 100% em todas as distros. Se isso já acontece, seria melhor insistir com esse formato, pois já existe e não precisaria reinventar a roda.
-
Komodor, eu não disse que o RPM resolveria todos os problemas. Mas se nem mesmo o formato RPM, que é o padrão do Linux, é adotado por distros populares como o Debian e o Ubuntu, o que esperar do resto? Seria necessário que primeiro se adotasse esse formato padrão, para depois procurar construir pacotes RPM que funcionassem em qualquer distro.
sim mas é que o RPM não foi criado para esses propósitos,o RPM não tem como ser multi-distro precisa criar outro,poi mudaria quase tudo (não 100%,mas quase)
se eu não me engano o RPM não foi adotado pelo debian por causa da politica do debian,acho que o RPM tem algum copyright da Red Hat,como no caso do firefox,que foi criado um fork pois não podia ser usado o nome e o logo,bem não tenho certeza se foi esse o motivo.
mas esse padrão ele não serve como base do sistema,ele não poderia ser usado para updates,o sistema em si,etc. ele pode até interagir mas não substitui.
o DEB,RPM,TGZ,etc para se mudar num sistema tem que mudar toda a base do sistema.este padrão ele é para ser adicionado ao sistema sem ter a necessidade de modificar a base.
uma das principais coisas é que ele vai criar um interface gráfica para a instalação. que o desenvolvedor projetar.
ele vai rodar no sistema não interferindo qual seu sistemas de pacotes padrão (deb,rpm,tgz,etc)
ele terá padrões em que acredito eu seria algo assim:
executar programa X (esse padrão estabeleceria o local aonde ele vai ser executado)
e acredito eu que seria ai que ele teria a compatibilidade
pois nos pacotes de hoje em dia como deb e rpm,ele manda executar num local especifico,se naquela distro ele não estiver lá ele retornara erro.entre outras coisas,como não sou programador eu não sei,teria que falar com o autor do post
o DEB, RPM, etc continuam sendo essenciais como base do sistema. ele não poderia substitui-los, como no caso dos updates
no caso do padrão adora o sistema base como RPM,e varias distros não seguirem é porque eles não veem como necessidade e os pacotes como deb trabalham de forma muito semelhante.e é integrado a todo o sistema,agora se o pessoal comesase a pedir por este padrão eles teriam que ver uma forma de um padrão multi-distro que não precisa mudar o todo o sistema. acredito que é este ponto que o autor pensou
-
O ideal seria que as distros top se reunissem e traçassem os parâmetros de como seria um pacote ideal, que funcionaria em qualquer distro sem muita gambiarra. Feito isso, fariam um protótipo e testariam o suporte dele em suas distros. Tudo ok? Então manda para a ISO transformar em um padrão e as próprias distros passam a usar esse padrão, mesmo que não deixem de usar seus próprios formatos de pacotes. A partir daí, teríamos um Linux mais padronizado, mesmo que as distros insistam em fazer suas próprias personalizações.
Existe o autopackage, que poderia fazer essa função, mas é preciso ver se ele realmente funciona 100% em todas as distros. Se isso já acontece, seria melhor insistir com esse formato, pois já existe e não precisaria reinventar a roda.
realmente essa idéia é boa,acho que poderia sim usar o autopackage como base e ir modificando como eles achem melhor. mas acredito que um dos principais problemas é que as distros não querem aceitar um formato padrão.e ai dificulta tudo,dai o pessoal tem que se juntar para que eles façam,se não isso nunca vai acontecer.
-
Komodor, eu não disse que o RPM resolveria todos os problemas. Mas se nem mesmo o formato RPM, que é o padrão do Linux, é adotado por distros populares como o Debian e o Ubuntu, o que esperar do resto? Seria necessário que primeiro se adotasse esse formato padrão, para depois procurar construir pacotes RPM que funcionassem em qualquer distro.
Só uma pergunta, porque o RPM é padrão do Linux?
-
Apoiado! Assino nas duas pontas!
Parabéns!
Marcopolo.
-
Komodor, eu não disse que o RPM resolveria todos os problemas. Mas se nem mesmo o formato RPM, que é o padrão do Linux, é adotado por distros populares como o Debian e o Ubuntu, o que esperar do resto? Seria necessário que primeiro se adotasse esse formato padrão, para depois procurar construir pacotes RPM que funcionassem em qualquer distro.
Só uma pergunta, porque o RPM é padrão do Linux?
Talvez por ter sido um dos primeiros, ou então o mais atualizado ou suportado pela indústria, ou então a Red Hat ter sido a primeira a propor que o formato seja padrão.
Quanto ao Debian, ele suporta sim o RPM, aliás, praticamente TODAS as distribuições o suportam, bastando instalar o pacote de bibliotecas do formato, até mesmo o Slackware que muitos criticam por não possuir gerenciamento de pacotes, suporta RPM.
Quando as restrições de licença, não existem, o formato é livre, acredito que o único motivo do Debian (e outros) não utilizar por padrão seja a birra mesmo, por preferir um formato próprio.
-
Talvez por ter sido um dos primeiros, ou então o mais atualizado ou suportado pela indústria, ou então a Red Hat ter sido a primeira a propor que o formato seja padrão.
Quanto ao Debian, ele suporta sim o RPM, aliás, praticamente TODAS as distribuições o suportam, bastando instalar o pacote de bibliotecas do formato, até mesmo o Slackware que muitos criticam por não possuir gerenciamento de pacotes, suporta RPM.
Quando as restrições de licença, não existem, o formato é livre, acredito que o único motivo do Debian (e outros) não utilizar por padrão seja a birra mesmo, por preferir um formato próprio.
Bom saber, em muitos anos de uso de Linux, e sempre lendo muito é a primeira vez que ouço que os pacotes RPM são padrão do Linux, e não apenas de distribuições baseadas no Red Hat (ou a própria).
-
Não sei se o RPM é padrão...
não seri apenas um tipo de "enpacotamento" diferente que assim como o deb guarda os programas pré compilados? se for isso continuamos com problema pois o que precisa ser realmente padronizado são os programas que fazem referencias a pastas incorretas dependendo da distro, estou certo?...
Mas como estou chegando agora no linux posso estar enganado..
abraços
-
Pessoas, eu particularmente não tenho grilo com a forma que as distros Linux gerenciam seus pacotes, acho que isso varia muito da característica de cada uma... assim como tem distros que usam o Gnome e outras que usam o KDE, tem as que usam pacotes .deb ou .rpm... são as variedades que compõem o ecosistema amplo que para mim é característica marcante do mundo Linux.
Mas, conferindo este tópico (http://www.meiobit.com/linux/depois_eu_quem_sou_implicante) da Fabiane no Meio Bit, onde ela fala sobre problemas com dependências no Fedora e o quanto isso pode ser irritante, vi num dos comentários (feito por nixcad) algo a respeito do Smart, um gerenciador de pacotes que, de acordo com o próprio site (tradução minha):
"(...) não é uma ponte mágica entre cada distribuição do planeta. Ao invés disso, este é um software que oferece melhor gerenciamento de pacotes para estas distribuições, até funcionando com seus próprios pacotes. Usar múltiplos gerenciadores de pacotes ao mesmo tempo (como rpm e dpkg) é possível, mesmo não sendo o objetivo do software nesse momento."
Pra quem quiser conferir, aqui vão os links para o Smart Package Manager:
Site principal: http://www.labix.org/smart (http://www.labix.org/smart)
Documentação em português do Brasil: http://www.zago.eti.br/smart-dicas.html (http://www.zago.eti.br/smart-dicas.html)
-
Eu usava o Smart no openSUSE, pois ele não era tão lento quanto o YaST, que é a ferramenta padrão dessa distro para gerenciar pacotes e mais uma porção de tarefas administrativas.
Devo dizer que o Smart não faz o milagre de se poder usar qualquer formato de pacote na distro que desejarmos, ela apenas trabalha com vários formatos, mas de acordo com a distro em que se está trabalhando!
Posso dizer que ele é muito similar ao Synaptic (se não me engano o criador de ambos é a mesma pessoa), mas ainda prefiro esse último!
Agora, o que se está propondo aqui, de se manter um formato único para empacotar os binários no Linux e assim podermos usar um pacote em qualquer distro é simplesmente impossível! O principal impecílio para isso está nas diferentes bibliotecas de desenvolvimenteo nas distros. Logo, as dependências não seriam atendidas! Se esse dia chegar, podem estar certo que será porquê estaremos com a existência de uma única distro! E então, seria possível??!!
Outra coisa: o apt ainda está para ser superado; é simplesmente o melhor! Principalmente com seu atual aptitude!
Ateh!
-
Pessoas, eu particularmente não tenho grilo com a forma que as distros Linux gerenciam seus pacotes, acho que isso varia muito da característica de cada uma... assim como tem distros que usam o Gnome e outras que usam o KDE, tem as que usam pacotes .deb ou .rpm... são as variedades que compõem o ecosistema amplo que para mim é característica marcante do mundo Linux.
Mas, conferindo este tópico (http://www.meiobit.com/linux/depois_eu_quem_sou_implicante) da Fabiane no Meio Bit, onde ela fala sobre problemas com dependências no Fedora e o quanto isso pode ser irritante, vi num dos comentários (feito por nixcad) algo a respeito do Smart, um gerenciador de pacotes que, de acordo com o próprio site (tradução minha):
"(...) não é uma ponte mágica entre cada distribuição do planeta. Ao invés disso, este é um software que oferece melhor gerenciamento de pacotes para estas distribuições, até funcionando com seus próprios pacotes. Usar múltiplos gerenciadores de pacotes ao mesmo tempo (como rpm e dpkg) é possível, mesmo não sendo o objetivo do software nesse momento."
Pra quem quiser conferir, aqui vão os links para o Smart Package Manager:
Site principal: http://www.labix.org/smart (http://www.labix.org/smart)
Documentação em português do Brasil: http://www.zago.eti.br/smart-dicas.html (http://www.zago.eti.br/smart-dicas.html)
claro,pois você não esta vendo pelo lado do desenvolvedor. o problema não é por nós usar um formato diferente de varias outras.
se fosse desenvolvedor tu iria preferir criar apenas um pacote que saberia que todas as distros iriam funcionar da mesma forma,ou quem sabe criar:
ubuntu: ubuntu 6.06, ubuntu 6.10, ubuntu 7.04, ubuntu 7.10.
dai mais os debian o estavel,o instavel o teste... e aquele monte.
mais as varias versões do mandriva,suse,fedora,red hat,etc
veja assim terá que criar no mínimo uns 80 pacotes diferentes se você quer que as principais distros.
como ele citou. o opensource a distro que se vire! agora softwares fechados não tem como fazer isso....
alem de que deb,rpm,etc não tem certas coisas como: pedir o serial do produto (muuuitos jogos precisa!)
selecionar o local de instalação
selecionar o que instalar (as vezes você não quer instalar algumas coisas do software)
etc.
você acha que uma empresa pequena,com poucos funcionários vão querer criar esses 80 pacotes,ter que manter todos. ou quem sabe só manter para windows e mac pois aquele tem só um pacote para cada....
-
Agora, o que se está propondo aqui, de se manter um formato único para empacotar os binários no Linux e assim podermos usar um pacote em qualquer distro é simplesmente impossível! O principal impecílio para isso está nas diferentes bibliotecas de desenvolvimenteo nas distros. Logo, as dependências não seriam atendidas! Se esse dia chegar, podem estar certo que será porquê estaremos com a existência de uma única distro! E então, seria possível??!!
é para se rir?
impossivel? tu nunca ouviu falar no autopackage? esse é um pacote que funciona em varias distros,não foi finalizado mas funciona em varias e ai?? cada a impossibilidade?
ou tu nunca viu os jogos feitos em (.run) ou (.bin)?? como UT2004 Doom's etc.é projetada pra tudo que distro mas para fazer isso,eles tem que fazer trilhões de coisas,muitas vezes da erro em certas distro pois não existe padrão,mas que funciona,eles normalmente criam toda uma interface em tk/tcl que da muito trabalho. para fazer certas coisas,e que nunca sabe se vai funcionar 100%
claro que vai dar conflito entre arquivos,caso você queira instalar um arquivo projetado em i386,e querer instalar em x86_64.
faz esse rebuliço todo porem tu não sabe nem o que diz.vai pesquisar antes de falar ok?
abaixa os (.run) ou (.package) e depois vem falar algo...
-
claro,pois você não esta vendo pelo lado do desenvolvedor. o problema não é por nós usar um formato diferente de varias outras.
se fosse desenvolvedor tu iria preferir criar apenas um pacote que saberia que todas as distros iriam funcionar da mesma forma,ou quem sabe criar:
ubuntu: ubuntu 6.06, ubuntu 6.10, ubuntu 7.04, ubuntu 7.10.
dai mais os debian o estavel,o instavel o teste... e aquele monte.
mais as varias versões do mandriva,suse,fedora,red hat,etc
veja assim terá que criar no mínimo uns 80 pacotes diferentes se você quer que as principais distros.
Realmente, não sou desenvolvedor, estou dando meu ponto-de-vista como utilizador do sistema e neste aspecto estou satisfeito, ainda não tive maiores problemas pra instalar os programas de que preciso, mesmo quando algum deles não está nos repositórios, o que no meu caso tem sido raro. Mas compreendo o quanto pode ser difícil para um desenvolvedor se responsabilizar pela manutenção de tantos tipos de pacote, ou como é complicado quando se quer instalar "aquele" programa e se descobre que a única forma de fazê-lo é compilando na unha...
como ele citou. o opensource a distro que se vire! agora softwares fechados não tem como fazer isso....
alem de que deb,rpm,etc não tem certas coisas como: pedir o serial do produto (muuuitos jogos precisa!)
selecionar o local de instalação
selecionar o que instalar (as vezes você não quer instalar algumas coisas do software)
etc.
O Ubuntu possui responsáveis pelos pacotes dos repositórios, e pela compatibilidade deles com o sistema. Nunca instalei um programa proprietário que me exigisse serial então não posso opinar sobre isso. Já instalei programas que me pediram o caminho da instalação (ex.: Firefox Widgets (http://ubuntuforums.org/showthread.php?t=369596)), no caso o instalador era gráfico, bastando apenas clicar encima do executável e dar permissão de execução quando questionado pelo sistema.
você acha que uma empresa pequena,com poucos funcionários vão querer criar esses 80 pacotes,ter que manter todos. ou quem sabe só manter para windows e mac pois aquele tem só um pacote para cada....
Windows e Mac OS tem uma forma bem distinta do Linux no que diz respeito à instalação dos programas, não existe o conceito de repositórios e pacotes como aqui. No caso do Mac me parece que nem existe uma instalação propriamente dita, é só jogar o executável na pasta Aplicativos, certo? Apesar de utilizar Macs com alguma regularidade, nunca instalei programas em um. Na minha opinião, a grande vantagem do sistema de repositórios e gerenciadores-de-pacote é a facilidade proporcionada por se ter uma lista de programas compatíveis com o sistema, todos prontos pra instalação/atualização (pelo menos no Ubuntu, via de regra, as dependências são resolvidas automaticamente quando se instala/atualiza algo via repositórios), o que torna a busca por determinado programa muito mais fácil e confiável. Sem repositórios/gerenciadores-de-pacote, como acontece no caso do Windows, o lance é sair à caça na net...
-
Realmente, não sou desenvolvedor, estou dando meu ponto-de-vista como utilizador do sistema e neste aspecto estou satisfeito, ainda não tive maiores problemas pra instalar os programas de que preciso, mesmo quando algum deles não está nos repositórios, o que no meu caso tem sido raro. Mas compreendo o quanto pode ser difícil para um desenvolvedor se responsabilizar pela manutenção de tantos tipos de pacote, ou como é complicado quando se quer instalar "aquele" programa e se descobre que a única forma de fazê-lo é compilando na unha...
pois é,mas olhe o lado de quem desenvolve softwares fechados,o código fonte não será disponibilizado. então eles não tem a opção de deixar você compilar,eles tem que compilar em varias distros.
pois funciona da seguinte maneira,se seu software é opensource e ele é considerado bom pela distribuição,eles pegam o código fonte (a distro) compilam e disponibilizam nos repositórios.
pois se eles disponibilizarem apenas para distro Y (no caso do sotware fechado),a tua pode até funcionar mas pode ter alguns erros,mas muitas pessoas irão se recusar de usar pois o software não foi projetado para o seu sistema
a porcentagem do linux no desktop e pouca,e ainda por cima não poder fazer com que todos utilizem por causa de diversas distros é um problema,alguns dizem que somos 5% (eu não sei,e só o que me disseram). dai você só cria para tais distros e vai atingir apenas 2% desses. (apenas uma ipotese)
O Ubuntu possui responsáveis pelos pacotes dos repositórios, e pela compatibilidade deles com o sistema. Nunca instalei um programa proprietário que me exigisse serial então não posso opinar sobre isso. Já instalei programas que me pediram o caminho da instalação (ex.: Firefox Widgets (http://ubuntuforums.org/showthread.php?t=369596)), no caso o instalador era gráfico, bastando apenas clicar encima do executável e dar permissão de execução quando questionado pelo sistema.
a questão dos programas que pedem serial,como por exemplo jogos de grandes empresas como valve. (counter strike,etc)
eles precisam pedir o serial,e o deb,rpm,etc não possibilitam isso,nem mesmo por exemplo deixar da instalar tal parte do programa,esses jogos tem normalmente uma opção de instalação completa e outra só com tais coisas
o que eles tem que fazer é criar um (.run) ou (.bin) que ele verifica todo o sistema e para cada sistema tem um procedimento diferente,ao passar isso é executado uma interface gráfica em tcl/tk (na maioria).
só que esse procedimento é tremendamente desagradável,pois eles tem que analisar as distros,ver como funciona em cada,quais as diferenças,verificar,executar o tal procedimento para sua distro (claro se sua for diferente das que eles preverão não ira funcionar. algo que se torna complexo (e muito..)
Windows e Mac OS tem uma forma bem distinta do Linux no que diz respeito à instalação dos programas, não existe o conceito de repositórios e pacotes como aqui. No caso do Mac me parece que nem existe uma instalação propriamente dita, é só jogar o executável na pasta Aplicativos, certo? Apesar de utilizar Macs com alguma regularidade, nunca instalei programas em um. Na minha opinião, a grande vantagem do sistema de repositórios e gerenciadores-de-pacote é a facilidade proporcionada por se ter uma lista de programas compatíveis com o sistema, todos prontos pra instalação/atualização (pelo menos no Ubuntu, via de regra, as dependências são resolvidas automaticamente quando se instala/atualiza algo via repositórios), o que torna a busca por determinado programa muito mais fácil e confiável. Sem repositórios/gerenciadores-de-pacote, como acontece no caso do Windows, o lance é sair à caça na net...
bem falei mal ao mencionar o MAC,pois não sei como funciona mas vamos ao fato do windows.
o windows tem os instaladores (.msi),mas a principal vantagem no windows é que ele não tem variantes. você irá criar um executavel e ele ira rodar no windows,pois não tem diferença de kernel,libs,etc.
sobre os repositorios,isso funciona perfeitamente no caso de um software opensource,ou até mesmo em alguns casos quando o software é fechado mas é gratuito.
vamos pegar um jogo de exemplo UT2004 (unreal tournament 2004),ele é codigo fechado e é um jogo pago. não pode colocar em nem um repositorio pois é pirataria. e assim por todos os jogos pagos
o pessoal pede muito jogos da EA por exemplo,se algum dia for lançado esses jogos para linux,nem um deles poderá ser colocado nos repositórios (a não ser o demo claro),pois estara infringindo as leis. que define como pirataria.
ai não tem jeito,tera que correr atrás na web por conta do jogo
-
Olá pessoal!
O formato RPM é padrão definido pelo Linux Standard Base. Mas parece que não pegou. É estranho, porque me lembro de uma entrevista do Patrick Volkerding, criador do Slackware onde ele diz que sua distro adotaris esse formato. Olhem o trecho onde ele diz isso:
A próxima versão do Slackware trará basicamente
versões mais novas dos programas que ele já possui, nada realmente
revolucionário. Mas para o futuro, estamos pensando em utilizar um
sistema de pacotes mais robusto. O sistema que usamos agora funciona
bem, e é interessante que o formato, sendo tar+gz, permita que os
pacotes sejam facilmente examinados e, se preciso, recompilados. Mas
gostaríamos de poder assiná-los, verificar o conteúdo, e manipular
upgrades de uma maneira mais automática. Nós estamos testando um
sistema experimental chamado SPS, mas também estamos considerando o
uso de formatos mais populares (e com mais suporte comercial) como o
RPM ou o DEB. O formato RPM é o candidato mais provável, por ser um
formato universal de fato e porque o Linux Standard Base (LSB)
provavelmente irá adotá-lo como formato padrão, e queremos estar em
conformidade já no lançamento do padrão.
http://www.slacklife.com.br/article.php?sid=1192 (http://www.slacklife.com.br/article.php?sid=1192)
Apesar do formato RPM ter sido mesmo o escolhido como padrão, não fiquei sabendo de nenhuma distro que mudou para esse formato. Acho que nem o Slackware mudou, apesar do que o Patrick disse nessa entrevista.
Agora, a reclamação em relação a binários pré-compilados não procede. No caso de um software comercial distribuído em binário, é só o desenvolvedor incluir um instalador e compilar estaticamente, ou incluir todas as dependências no pacote. É mais ou menos isso que é feito no Windows.
-
eu sei q eu não deveria me intrometer, já q eu não tenho muito conhecimento na área, mas é q eu tenho uma dúvida...
não era melhor fazer uma interface gráfica bonita e bem "autoexplicativa" para instalar aplicativos *.bin e *.run e torna-los padrão para o linux? sei lá... aí para q não haja problema com o "instalador" todos eles deveriam vir com comentários ou algum trecho com algumas especificações necessárias para q a instalação aconteça sem problemas e sem dificuldades através desse programa. entenderam?
isso é possível? se não, pq?
-
Talvez se saísse algo parecido com o Installshield pro Linux. É a ferramenta mais usada pra criar instaladores pro Windows.
-
Talvez se saísse algo parecido com o Installshield pro Linux. É a ferramenta mais usada pra criar instaladores pro Windows.
Na verdade, já existe. O InstallShield é uma ferramenta comercial da empresa Macrovision. A mesma Macrovision tem uma outra ferramenta chamada InstallAnywhere, veja a descrição:
The InstallAnywhere 8 installation toolset enables software developers to create high-quality, standardized installations for multiple platforms, including Unix, Linux, Mac OS and Windows.
http://www.macrovision.com/products/installation/installanywhere.htm (http://www.macrovision.com/products/installation/installanywhere.htm)
Isso sem falar que não é tão complicado assim criar um instalador usando ferramentas livres. Dá para fazer até mesmo em shell script, ou em tcl/tk, como foi citado em outro post.
O que acontece no caso dos desenvolvedores de software livre é que eles simplesmente não se preocupam com isso. Geralmente eles só distribuem o código do fonte e deixam que as distros ou pessoas interessadas criem os pacotes para Linux e outro sistemas. O código fonte é praticamente univerdsal, através dele você instala em qualquer distro e também em outros sistemas, como os Bsds, Solaris, MacOSX, às vezes até no Windows. Já no caso dos desenvolvedores de software proprietário, eles já usam ferramentas comerciais, como o InstallShield no ambiente Windows, ou criam eles mesmos seus próprios intaladores. Não teria porque não fazer o mesmo no Linux.
-
creio que não seja preciso mas seria bom...
poderiam haver scripts para instalar pacotes rpm atraves do alien e scripts para instalar tgz,tar.gz e bz2
-
Olá colegas,
Não sou programador, apenas participo como integrante do fórum e interessado.
Não sei se é possível, pois o Linux teve varias vertentes após sua criação.
O que por um lado foi muito bom (houve progresso em todos segmentos) por outro dificultou bastante seu ingresso aos PCs domesticos.
Se isso for possível sem perda de qualidade para o sistema e os softweres eu concordo, acho que seria a melhor solução e definitiva, então eu assino em baixo.
Abraços
-
ah cara... sei lá viu... eu, na minha opinião, acho até bom que não tenha esta "padronização", porque se padronizar, tudo começar a ficar muito igual...
-
poderiam haver scripts para instalar pacotes rpm atraves do alien e scripts para instalar tgz,tar.gz e bz2
converter pacotes .rpm com o alien, nem sempre dá certo, dando uma idéia de gambiarra :P
-
ah cara... sei lá viu... eu, na minha opinião, acho até bom que não tenha esta "padronização", porque se padronizar, tudo começar a ficar muito igual...
Num acho que vá ficar nada igual, não. O que se está discutindo aqui é a padronização de pacotes, não de sistema. Como já foi dito antes, todas as distribuições poderão continuar com seus pacotes próprios, a única diferença é que aceitarão também um pacote padrão. É a mesma coisa das extensões dos arquivos: a ISO padronizou o ODF, e o Office 2007 da MS já aceita esse padrão, além de suas extensões proprietárias. Ainda assim, o Open/BrOffice é bastante diferente do Office 2007. Não tem nada a ver uma coisa com a outra.
-
Eu, particularmente, sou contra.
Existem muitas falhas em certos controladores de pacotes, que em outros não têm, e adotar uma base vai ser difícil de satisfazer a todos. De certo modo, eu ainda prefiro que se mantenham distribuindo pacotes para as distros mainstream, e a souce para outras distros. Aqui no arch, eu uso o Pacman, que é extremamente interessante, mas não trabalha com deb nem rpm.
Liberdade de Escolha prevalece, na minha opinião.
-
Penso que o suporte a um padrão é nescessário sim, os mantenedores de distribuições não precisam abandonar seu sistema atual, não é impossível suportar dois sistemas de pacotes.
E mesmo que todas abandonassem o antigo isso não afetaria a liberdade do usuário, pois essa não está no fato de usar .rpm ou .deb e sim ter acesso ao source.
-
Eu, particularmente, sou contra.
Existem muitas falhas em certos controladores de pacotes, que em outros não têm, e adotar uma base vai ser difícil de satisfazer a todos. De certo modo, eu ainda prefiro que se mantenham distribuindo pacotes para as distros mainstream, e a souce para outras distros. Aqui no arch, eu uso o Pacman, que é extremamente interessante, mas não trabalha com deb nem rpm.
Liberdade de Escolha prevalece, na minha opinião.
sabe porque existem falhas? porque eles não se juntaram para fazer nada! pois assim nunca irá ter um pacote para todos que funcione perfeitamente.agora se os caras que comandam as distros se juntassem para fazer ai esses bugs não existiriam
"e a souce para outras distros"
peça as sources de um software privado (como um jogo por exemplo ut2004) para ver se eles irão te mandar
"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).
num caso hipotético que esse padrão fosse feito,você teria a opção de lançar neste pacote ou senão nos outros. mas para alguém que não trabalha com um grupo grande não vai preferir criar pacotes individuais para cada distribuição,sendo que aquele padrão irá funciona nas outras sem problema
sempre liberdade de escolha,isso nunca irá mudar em gnu/linux
-
Existem muitas falhas em certos controladores de pacotes, que em outros não têm, e adotar uma base vai ser difícil de satisfazer a todos. De certo modo, eu ainda prefiro que se mantenham distribuindo pacotes para as distros mainstream, e a souce para outras distros.
Liberdade de Escolha prevalece, na minha opinião.
São coisas que eu também levo em consideração... se eu der minha opinião pessoal, vou dizer que pacotes Debian são a melhor escolha para ser a base de um padrão único, visto que minha experiência com eles é muito satisfatória. Mas quem tem preferência por pacotes RPM com toda a certeza vai discordar de mim, provavelmente enumerando as vantagens deste tipo de pacote e porque ele deveria ser tomado como base para uma padronização. A pluralidade de pontos-de-vista e as múltiplas formas de se montar um sistema no Linux leva à estas variedades, é difícil querer estabelecer um padrão único para algo que é intrinsecamente diverso.
Quanto à comparação com o ODF, existem sensíveis diferenças. O caso é que já existe um padrão "de facto" para edição de documentos atualmente, que é o formato proprietário da Microsoft. O problema aí é que este é um formato fechado, não há possibilidade de se seguir este padrão, porque não é possível conhecer suas especificações. Vendo por este ângulo, sequer se trata de um padrão, já que não pode ser seguido! O ODF vem a corrigir esta distorção, lançando um padrão de documento aberto, passível de ser utilizado por qualquer suíte office.
Pois bem, apesar de não ser único, acho que os formatos de empacotamento que temos no Linux de certa forma são padrões, visto que são abertos e passíveis de adaptação. Vejamos a definição do termo padrão dada pela ISO (http://pt.wikipedia.org/wiki/ISO), extraída da Wikipédia (http://pt.wikipedia.org/wiki/Padr%C3%A3o):
"(...) um padrão é um 'documento aprovado por um organismo reconhecido que provê, pelo uso comum e repetitivo, regras, diretrizes ou características de produtos, processos ou serviços cuja obediência não é obrigatória'".
Não sei dizer se os tipos de pacotes são aprovados por algum organismo reconhecido, mas eles são de uso "comum e repetitivo", cada um dentro de seu contexto. A obediência à eles também não é obrigatória, visto que por sua natureza open-source, são passíveis de adaptação, ou inclusive podem ser substituídos um pelo outro, ou ainda por um terceiro (alguém que, por exemplo, cria uma nova distro baseada em outra anterior, substituindo seu programa gerenciador de pacotes).
Compreendo a necessidade de quem necessita do estabelecimento de um padrão de empacotamento para distribuir softwares no Linux, inclusive um tempo atrás ví algo no blog do Flash para Linux que falava a respeito disso. É uma necessidade importante para produtores de soft proprietário, que por não abrirem suas especificações não podem simplesmente entregar seus programas para as distros empacotarem. E claro, para desenvolvedores menores, como frisou o Komodor anteriormente, não deve ser tarefa fácil manter um número tão variado de pacotes, compatível com tantas distros... Mas até pela natureza livre do sistema, onde geralmente padrões não são impostos "de fora pra dentro", e sim ao contrário (o uso condiciona o padrão, ao invés do padrão condicionar o uso), esta padronização pode ter um grande desafio pela frente...
Enfim, acho que o SL esta sempre aberto (por natureza) à demanda de quem necessita dele, e mesmo que não surja um padrão universal para pacotes, à medida que a demanda por programas que precisem de um determinado padrão para distribuição atinja massa crítica, acredito que pode brotar algo que dê conta desse recado. ;)
-
Quanto à comparação com o ODF, existem sensíveis diferenças. O caso é que já existe um padrão "de facto" para edição de documentos atualmente, que é o formato proprietário da Microsoft. O problema aí é que este é um formato fechado, não há possibilidade de se seguir este padrão, porque não é possível conhecer suas especificações. Vendo por este ângulo, sequer se trata de um padrão, já que não pode ser seguido!
Não sei se o colega entendeu minha comparação. Tudo isso que você falou em relação ao ODF e doc é verdade e eu já sabia. Eu sei que há diferenças, mas eu comparei apenas para mostrar que a existência de padrões em nada interfere na escolha individual de cada um. Eu poderia ter comparado com qualquer outra coisa, era apenas uma ilustração.
sabe porque existem falhas? porque eles não se juntaram para fazer nada! pois assim nunca irá ter um pacote para todos que funcione perfeitamente.agora se os caras que comandam as distros se juntassem para fazer ai esses bugs não existiriam
Perfeito, Komodor. Essa campanha em favor de padronização de pacotes (que, repito, nada tem a ver com padronização de sistemas) deve ter como objetivo sensibilizar os mantenedores das distros para que escolham e passem a aceitar TAMBÉM um tipo de pacote padrão. E para isso, eles têm que se reunir e fazer acontecer.
-
É conhecida alguma outra iniciativa internacional com o mesmo propósito?
-
Para mim, esta é uma discussão bastante simplista. O problema não está no formato do pacote, se RPM, DEB, TGZ, TAR.GZ.PKG, etc. Como foi dito acima, se duas versões do sistema são incompatíveis, não há pacote que resolva. O ramo unstable (Sid) do Debian também usa os mesmíssimos pacotes DEB do ramo estável (Etch), mas os pacotes de cada um deles podem ser incompatíveis simplesmente porque se trata de versões diferentes e pronto! Um Ubuntu lançado em outubro de 2007, com o Gnome 2.20, não será compatível com o Debian Etch, que foi lançado no início deste ano, ainda com o Gnome 2.16! E o problema das dependências: uma distro menos focada no conforto pode até mesmo aceitar o controle de dependências (com a instalação automática das mesmas), mas é bem possível que o pessoal do Slackware, por exemplo, acredite que o mesmo programa exija muito menos dependências que o pessoal do Ubuntu atribuiria ao mesmo. E o tipo de pacote - DEB, RPM ou TGZ, - tem muito pouco a ver com isto.
O que muitos não percebem é que a única forma que o Windows encontrou de resolver o problema foi tornar cada uma de suas versões totalmente compatível com as outras. Mas isto sempre deu tanto trabalho ao desenvolvimento deste sistema que terminou sendo parcialmente abandonado pelo Vista: muitos executáveis do XP simplesmente não funcionam no Vista, exatamente, aliás, como boa parte dos pacotes do Debian Sid não funciona no Etch.
Portanto, a existência de um pacote padrão dificilmente resolveria o problema da incompatibilidade entre distros distintas. Os pacotes adequados a uma distro que privilegia a atualidade dos programas (como a Arch, Ubuntu, etc.) seriam sempre incompatíveis com aqueles outros de uma distro que privilegia a estabilidade (como o Debian, Slackware, etc.). E é bom que isto continue assim.
Desse modo, se todas adotassem o RPM, ainda assim haveria a necessidade de um RPM para a Suse, outro para a Fedora, outro para a Yoper e assim por diante. A vida só ficaria fácil mesmo para o desenvolvedor, que teria que aprender a empacotar apenas no formato RPM. Não sei se é uma vantagem que vale a pena, ante os prejuízos sofridos pela natural diversidade do mundo Linux.
Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.
-
Uma coisa que acho que muita gente ainda não entendeu é que é perfeitamente possível ter pacotes de software pré-compilado que funcionam em qualquer distro. O Opera, por exemplo, tem pacotes para várias distros, mas também tem uma versão compilada estaticamente que funciona em qualquer distro. Essa versão existe tanto em RPM como em DEB, mas também num simples pacote tar.gz que pode ser usado até em distros que não suportam esses formatos de pacotes, é só descompactar e usar. Se o formato RPM fosse mesmo suportado por todas as distros, então eles nem precisariam distribuir em deb e tar.gz. Eles e qualquer outro produtor de software fechado poderiam simplesmente distribuir apenas um pacote RPM compilado estaticamente, que poderia ser instalado em qualquer distro. E caso tivessem interesse poderiam fazer, como o Opera faz atualmente, pacotes específicos, compilados dinamicamente, para as distros mais populares.
-
Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.
Desculpa, mas não sei o que tem a ver...
-
Não sei se o colega entendeu minha comparação. Tudo isso que você falou em relação ao ODF e doc é verdade e eu já sabia. Eu sei que há diferenças, mas eu comparei apenas para mostrar que a existência de padrões em nada interfere na escolha individual de cada um. Eu poderia ter comparado com qualquer outra coisa, era apenas uma ilustração.
Compreendi Vinicius. Apenas peguei o gancho da tua ilustração pra trazer à tona essa questão da padronização e de como ela pode ser vista em diferentes contextos.
Para mim, esta é uma discussão bastante simplista. O problema não está no formato do pacote, se RPM, DEB, TGZ, TAR.GZ.PKG, etc. Como foi dito acima, se duas versões do sistema são incompatíveis, não há pacote que resolva. O ramo unstable (Sid) do Debian também usa os mesmíssimos pacotes DEB do ramo estável (Etch), mas os pacotes de cada um deles podem ser incompatíveis simplesmente porque se trata de versões diferentes e pronto!
Constatação interessante, Piras.
Os pacotes adequados a uma distro que privilegia a atualidade dos programas (como a Arch, Ubuntu, etc.) seriam sempre incompatíveis com aqueles outros de uma distro que privilegia a estabilidade (como o Debian, Slackware, etc.). E é bom que isto continue assim.
Exato. Diferente do Windows ou do Mac OS, as distros Linux primam por sua especificidade, penso que existe um fino equilíbrio entre cada um de seus componentes, e as características de cada uma delas pode ser definida por este equilíbrio. O tipo de pacote utilizado é apenas mais uma peça deste processo, tão fundamental quanto todo o resto.
Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.
Penso que são sistemas diferentes, e diferentes paradigmas...
Uma coisa que acho que muita gente ainda não entendeu é que é perfeitamente possível ter pacotes de software pré-compilado que funcionam em qualquer distro.
Cara, instalei o Googleearth através de um destes "genéricos" (acho que era um .run) e a instalação foi fácil e fluída, tanto quanto é o funcionamento do programa. Abri o Nautilus como root>>duplo-clique no .run>>executar em terminal... instalado.
-
Para mim, esta é uma discussão bastante simplista. O problema não está no formato do pacote, se RPM, DEB, TGZ, TAR.GZ.PKG, etc. Como foi dito acima, se duas versões do sistema são incompatíveis, não há pacote que resolva. O ramo unstable (Sid) do Debian também usa os mesmíssimos pacotes DEB do ramo estável (Etch), mas os pacotes de cada um deles podem ser incompatíveis simplesmente porque se trata de versões diferentes e pronto! Um Ubuntu lançado em outubro de 2007, com o Gnome 2.20, não será compatível com o Debian Etch, que foi lançado no início deste ano, ainda com o Gnome 2.16! E o problema das dependências: uma distro menos focada no conforto pode até mesmo aceitar o controle de dependências (com a instalação automática das mesmas), mas é bem possível que o pessoal do Slackware, por exemplo, acredite que o mesmo programa exija muito menos dependências que o pessoal do Ubuntu atribuiria ao mesmo. E o tipo de pacote - DEB, RPM ou TGZ, - tem muito pouco a ver com isto.
veja o caso do autopackage.
http://www.autopackage.org/
estes pacotes vão instalar tanto no meu ubuntu,quando no gentoo do meu amigo,quando no fedora,slack,etc.
distribuições totalmente diferentes! (ou você acha que não?) funcionam! o que ocorre é que você esta comparando deb,rpm,.tar.gz (puts da pra ve que tu não entende nada ao comparar o .tar.gz)
como eu ja disse trilhões de vezes. o deb,rpm,são pacotes diferentes... sem a POSSIBILIDADE de se fazer um pacote multi-distro.
eles só pegam os binários dentro do pacote,e colocam a pasta especificada de instalação. o que mais ele faz é verificar as dependências. não tem INTERFACE GRÁFICA!,NÃO TEM COMO PEDIR SERIAL OU ATÉ MESMO O LOCAL A INSTALAÇÃO.comparar um rpm e um deb por não funcionarem em varias distros é totalmente sem cabimento.
o que vocês pensam é que seria só um pacote como um rpm ou deb e se renomeia para algum outro nome e pronto,se fosse isso ninguém iria estar perdendo tempo aqui. a questão é que o pacote tem que ser como um autopackage desenvolvido pelas distros,é possível sim funcionar em qualquer distro basta ter a coperação entre eles
é obvio que pode ter problemas que alguns programas não funcionem em todas as distros. se tu faz um programa para interagir com o gnome e tu não tem gnome não irá funcionar,é obvio! mesma coisa que tu criar um jogo para rodar o som em ALSA e a distro só aceita OSS.
a questão é que hoje em dia com rpm,deb,etc nem se tu tem todos os componentes da mesma versão irá funcionar de uma para outra distro,com uma padronização claro que iria funcionar se a distro estivesse com os requisitos especificados pelo padrão
O que muitos não percebem é que a única forma que o Windows encontrou de resolver o problema foi tornar cada uma de suas versões totalmente compatível com as outras. Mas isto sempre deu tanto trabalho ao desenvolvimento deste sistema que terminou sendo parcialmente abandonado pelo Vista: muitos executáveis do XP simplesmente não funcionam no Vista, exatamente, aliás, como boa parte dos pacotes do Debian Sid não funciona no Etch.
uma coisa que vejo que tu não tem idéia do que fala é que os programas do windows,em 98% dos casos não é um pacote instalador,e sim pura e simplesmente um executável,pois o windows não tem variantes irá funcionar sempre,se tu tem winxp,compilar para ele o outro que tiver vai rodar também.
o kernel do xp pro vista teve uma mudança completa.isso faz com que o sistema não tenha compatibilidade, o que no caso do linux.tu vai criar o programa para o kernel 2.6 em muitos casos até para 2.4 em diante. o kernel não se modificou todo a esse ponto,a maioria das distros usa o 2.6 (uns 95% pelomenos)
um pacote instalador não é um executável,ou você achava que os (.exe) do windows erão pacotes?
Portanto, a existência de um pacote padrão dificilmente resolveria o problema da incompatibilidade entre distros distintas. Os pacotes adequados a uma distro que privilegia a atualidade dos programas (como a Arch, Ubuntu, etc.) seriam sempre incompatíveis com aqueles outros de uma distro que privilegia a estabilidade (como o Debian, Slackware, etc.). E é bom que isto continue assim.
explique-me o porque os programas em autopackage funcionam em muitas distros,sem edições nem uma?
ou intão os programas com (.bin) e os (.run) vou citar alguns:
IBM Symphony
Unreal Tournament 2004
Doom3
etc.
realmente devo estar bêbado esses programas não existem...
Desse modo, se todas adotassem o RPM, ainda assim haveria a necessidade de um RPM para a Suse, outro para a Fedora, outro para a Yoper e assim por diante. A vida só ficaria fácil mesmo para o desenvolvedor, que teria que aprender a empacotar apenas no formato RPM. Não sei se é uma vantagem que vale a pena, ante os prejuízos sofridos pela natural diversidade do mundo Linux.
como eu disse o RPM seria impossivel de se fazer qualquer coisa deste modo,o que ocorre,é que vocês não leem todo o tópico vem na ultima pagina sem entender nada e ficam falando umonte de abobrinha
Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.
sem comentários.....
-
Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.
Piras, isto é absolutamente verdadeiro, e já disse isso várias vezes nesse fórum. Mas você erra em achar que é impossível um pacote universal, que funciona em qualquer distro. Isto tanto é possível que já existe.
Mas o problema maior é que muitas pessoas querem que simplesmente seja extintos os sistemas de pacotes do Linux, e seja adotado algo parecido com o Windows. Mas aí é porque essas pessoas não só não conhecem Linux, como nem sabem como isso é feito no Windows. Pensam que no Windows existe um padrão, quando na realidade é uma bagunça, cada desenvolvedor faz o que quer. É comum, inclusive, esses instaladores substituírem as bibliotecas do sistema por versões próprias, resultando muitas vezes em instabilidade do sistema e lentidão, quando não em surgem incompatibilidades com outros softwares. Falam do que não conhecem. O próprio "artigo" citado no início do tópico é muito ruim, e veja que citaram até a tal de Fabiane não sei das quantas. Com o pessoal do fórum com leituras desse tipo não é de se admirar que surjam essas propostas sem pé nem cabeça.
-
Como foi dito antes, ao Autopackage é uma iniciativa para padronizar a instalação de aplicações.
Vejam mais info aqui:
Autopackage: Toward a universal package manager for the desktop
-
Mas o problema maior é que muitas pessoas querem que simplesmente seja extintos os sistemas de pacotes do Linux, e seja adotado algo parecido com o Windows. Mas aí é porque essas pessoas não só não conhecem Linux, como nem sabem como isso é feito no Windows. Pensam que no Windows existe um padrão, quando na realidade é uma bagunça, cada desenvolvedor faz o que quer.
espero que não esteja se referenciando a mim,pois ai a unica conclusão que tenho é que você só vem neste tópico para gerar intrigas nada mais..
eu em hipótese alguma dei referencias do windows como alvo deste padrão nem mesmo o autor do tópico. o que houve e que alguns "usuários" do forum ficaram falando que eu queria transformar o linux em windows,e dando referencias aos pacotes do windows.
mas parece que vou ter que repetir aqui pois tem gente que gosta de não ler as mensagens anteriores (será que realmente não virão?!?)
o WINDOWS,é esse sistema mesmo em que vocês em tudo que tentarmos fazer vocês tem que dizer que estamos imitando.não há variantes. uma vez que foi criado o windows xp,é só ele.e com isso não há diferenças entre kernel,ou qualquer parte do sistema dele e dos usuários,ele só irá usar um pacote se ele não souber criar um instalador,no windows é muito raro se ver o pessoal usar pacotes,eles criam um instalar e compilam e pronto,é um executável e não um pacote,um executável ele é o binário puro caso não tenha percebido ainda
acham que porque é algo para facilitar então logo associam com o windows e logo vem esse monte de associações tolas e inúteis.
É comum, inclusive, esses instaladores substituírem as bibliotecas do sistema por versões próprias, resultando muitas vezes em instabilidade do sistema e lentidão, quando não em surgem incompatibilidades com outros softwares. Falam do que não conhecem.
quem sabe se você tentasse ler o que eu falo em tantos tópicos aqui?? (pois é tem gente que tem preguiça...)
o autopackage que eu tanto falo.
1º não tem como ser uma copia do windows,pois ele não é simplesmente um binario
2º o autopackage tem o sistema de verificar dependências!! não ira ser como no windows que o desenvolvedor não tem escolha e tem que meter as bibliotecas no sistema e pronto. substituindo.
a questão é que você não tem idéia nem de como funciona o autopackage sendo assim você ACHA que é parecido com windows,coloca umonte de comentário sem sentido e ainda quer dar lição de moral
O próprio "artigo" citado no início do tópico é muito ruim, e veja que citaram até a tal de Fabiane não sei das quantas. Com o pessoal do fórum com leituras desse tipo não é de se admirar que surjam essas propostas sem pé nem cabeça.
pelo que me parece em todos os teus argumentos leigos,eu mostrei que não tem sentido nem um. isso até parece coisas de crianças "isso é ruim!!","mas porque é ruim?" "porque é!!!"
boi não tenho nada contra ti mas cara. vem dar essas indiretas e essas comparações mais absurdas que eu não tem cabimento nenhum e vem ainda querer falar:
"Com o pessoal do fórum com leituras desse tipo não é de se admirar que surjam essas propostas sem pé nem cabeça."
francamente tem pessoas que não tem noção... (caso esteja com isso pelo lado pessoal,então use a MP)
-
Como foi dito antes, ao Autopackage é uma iniciativa para padronizar a instalação de aplicações.
Vejam mais info aqui:
Autopackage: Toward a universal package manager for the desktop
pois é,o autopackage é um pacote muito bom,o problema é que não tem uma integração com as desenvolvedores das distribuições principais,ai não é em todos os casos que essa ferramenta funciona,pois hoje em dia ela é usada só para alguns tipos de aplicativos.
se existisse um olhar especial pelos desenvolvedores isso seria uma beleza,ninguém iria se privar de nada.e só acrescentar,mas precisaria da cooperação dos desenvolvedores de grandes distribuições.
que poderiam usar o autopackage como base ou até melhorar ele para não ter de forma alguma problemas de incompatibilidade ao passar do tempo e as distros irem mudando
-
Komodor, se você ler minhas mensagens, vai ver que em nenhum momento falei do autopackage. Nem mesmo estava me referindo especificamente a você quando falei desses usuários que querem que o Linux copie tudo do Windows. Esse é um problema geral, muitos usuários do fórum insistem em que o Linux copie tudo do Windows, inclusive os defeitos. Mas é claro que você se inclui entre estes.
E antes de dizer que o pessoal daqui só diz "abobrinha", como você colocou em outro post, procure antes entender melhor o que é o Linux. E se possível, procure também entender o que é o Windows. Procure selecionar melhor os sites que visita na net. Procure melhorar sua interpretação de textos e também, se possível, passar a escrever melhor. Aí talvez você deixe de considerar "abobrinhas" as opiniões que apenas são diferentes das suas.
-
Komodor, se você ler minhas mensagens, vai ver que em nenhum momento falei do autopackage. Nem mesmo estava me referindo especificamente a você quando falei desses usuários que querem que o Linux copie tudo do Windows. Esse é um problema geral, muitos usuários do fórum insistem em que o Linux copie tudo do Windows, inclusive os defeitos. Mas é claro que você se inclui entre estes.
você podia estar naquela parte até sem se referir diretamente a mim,mas esta parte ficou clara pra mim:
"O próprio "artigo" citado no início do tópico é muito ruim, e veja que citaram até a tal de Fabiane não sei das quantas. Com o pessoal do fórum com leituras desse tipo não é de se admirar que surjam essas propostas sem pé nem cabeça."
lendo esta parte é obvio que associei o resto como sendo direcionado tambem
E antes de dizer que o pessoal daqui só diz "abobrinha", como você colocou em outro post
não generalize,eu falei sim que existe um pessoal,não falei de todos,eu intendo que tem opinião contraria e respeito,porem espero que a pessoa não venha a mim com este tipo de coisas:
"Com o pessoal do fórum com leituras desse tipo não é de se admirar que surjam essas propostas sem pé nem cabeça."
pois em todo o tópico eu mantive as respostas explicativas de cada coisa,de meu ver,como funciona.etc
a abobrinha pode ser amenizda com as "propostas sem pé nem cabeça"
procure antes entender melhor o que é o Linux. E se possível, procure também entender o que é o Windows. Procure selecionar melhor os sites que visita na net. Procure melhorar sua interpretação de textos e também, se possível, passar a escrever melhor. Aí talvez você deixe de considerar "abobrinhas" as opiniões que apenas são diferentes das suas.
no que você esta dizendo que devo aprender windows e linux? está se referindo que linux é sistema completamente diferente e não pode nunca ter facilidades pois o windows é conhecido por ser fácil?
posso até não escrever da melhor forma,mas o mais importante é que mostro o meu ponto de vista e as circunstâncias reais,não sei se você se refere meus textos como confusos ou sendo agressivos,mas eu só usei o mesmo tipo de expressão que você,igual ao seu ultimo parágrafo da outra mensagem
ok eu deixo de considerar suas mensagens como abobrinha e você deixa de considerar as minhas mensagens "sem pé nem cabeça" :P
-
Eu, particularmente, sou contra.
Existem muitas falhas em certos controladores de pacotes, que em outros não têm, e adotar uma base vai ser difícil de satisfazer a todos. De certo modo, eu ainda prefiro que se mantenham distribuindo pacotes para as distros mainstream, e a souce para outras distros. Aqui no arch, eu uso o Pacman, que é extremamente interessante, mas não trabalha com deb nem rpm.
Liberdade de Escolha prevalece, na minha opinião.
"e a souce para outras distros"
peça as sources de um software privado (como um jogo por exemplo ut2004) para ver se eles irão te mandar
Me dá a lista de arquivos que eu crio um pacote facilmente para o Arch.
Isso não é problema. A questão é o seguinte, eu não gosto do APT, se ele se tornar padrão, eu terei que usar ele, porque só serão distribuídos pacotes em .deb. E onde fica minha liberdade de escolha?
-
Estou com o s4suk3. Eu por exemplo gosto do apt, e descobri recentemente (na verdade quem descobriu foi o Mythus) que a grande maioria das distros que usei tinham a ferramenta. Acho que quem conviveu com liberdade até aqui (para escolher o melhor gerenciador de pacotes, a interface gráfica e etc) não vá gostar muito de ser obrigado a aceitar um padrão de forma forçada.
Além do mais (opinião pessoal) ferramentas como o Apt dão um show na forma de trabalho da Microsoft.
[]'s
Cristiano.
-
você podia estar naquela parte até sem se referir diretamente a mim,mas esta parte ficou clara pra mim:
"O próprio "artigo" citado no início do tópico é muito ruim, e veja que citaram até a tal de Fabiane não sei das quantas. Com o pessoal do fórum com leituras desse tipo não é de se admirar que surjam essas propostas sem pé nem cabeça."
lendo esta parte é obvio que associei o resto como sendo direcionado tambem
Eu citei o tópico da Fabiane no Meio Bit (http://www.meiobit.com/linux/depois_eu_quem_sou_implicante) porque achei que cabia bem como exemplo de problemas que podem ser gerados por dependências e formas de solucioná-los (nos comentários). No mais, não tenho nada contra os textos dela, embora também não concorde com tudo o que ela diz. Inclusive, fui instigado a testar o Fedora 7 lendo o post em seu blog pessoal (http://megalopolis.blogarium.net/?p=513), onde ela relata ter tido problemas com Ubuntu (que agora ela também enfrenta no Fedora), que toca justamente na questão das dependências. Não vou julgar méritos, mas achei válida a experiência e pertinente ao assunto deste tópico.
Estou com o s4suk3. Eu por exemplo gosto do apt, e descobri recentemente (na verdade quem descobriu foi o Mythus) que a grande maioria das distros que usei tinham a ferramenta. Acho que quem conviveu com liberdade até aqui (para escolher o melhor gerenciador de pacotes, a interface gráfica e etc) não vá gostar muito de ser obrigado a aceitar um padrão de forma forçada.
E eu estou com vocês dois. Já tive um problema ou outro em função das dependências, mas nada que me fizesse perder a cabeça ou cogitar uma mudança de distro. Gosto da forma como o Ubuntu gerencia seus pacotes e não sou tão exigente a ponto de querer que ele seja a prova de falhas, nem ingênuo demais pra pensar que nunca terei problemas com ele (como teria em qualquer outro sistema). Minha experiência com o APT é muito positiva, mas gosto de ter liberdade de mudar de idéia se vier ao caso, seja pra trocar de pacote/gerenciador, interface gráfica, ou o que seja dentro do meu sistema.
-
Eu, particularmente, sou contra.
Existem muitas falhas em certos controladores de pacotes, que em outros não têm, e adotar uma base vai ser difícil de satisfazer a todos. De certo modo, eu ainda prefiro que se mantenham distribuindo pacotes para as distros mainstream, e a souce para outras distros. Aqui no arch, eu uso o Pacman, que é extremamente interessante, mas não trabalha com deb nem rpm.
Liberdade de Escolha prevalece, na minha opinião.
"e a souce para outras distros"
peça as sources de um software privado (como um jogo por exemplo ut2004) para ver se eles irão te mandar
Me dá a lista de arquivos que eu crio um pacote facilmente para o Arch.
Isso não é problema. A questão é o seguinte, eu não gosto do APT, se ele se tornar padrão, eu terei que usar ele, porque só serão distribuídos pacotes em .deb. E onde fica minha liberdade de escolha?
deb,rpm etc. nunca serão padrão como ja cito desdo inicio do tópico. esses são pacotes nativos dos sistemas,eles não podem ser substituído,não tem como mexer nele,qualquer distro que aceita-se o padrão ficaria com o seus pacotes nativos (rpm,deb,tgz,etc.)
não vejo como pode deter a liberdade olhe porque:
padrão não é feito para ti obrigar a usa-lo,se tu usar tu vai criar nele e vai funcionar em varias distro tu não é obrigado a criar para ele!
para programas que distribuem deb,rpm,etc esses provavelmente não mudarão,pois não há necessidade!!! é apenas uma facilidade a mais.e ter certeza que vai funcionar em todas só isso
se você quiser você tambem pode recriar esses arquivos para seu pacote padrão,vendo como funciona e criando para o seu e ponto.
e os milhares de programas que são feitos em (.run) e (.bin) você considera eles detentores da sua liberdade de escolha? eu poderia dizer o mesmo de se fazer para (.rpm) pois eu utilizo (.deb) então todos que só fazem em (.rpm) estão tirando a minha liberdade
ressaltando sempre,que padrão é não obrigação! por exemplo o odt que foi decidido pela ISO,isso faz com que tu seja obrigado a usar só e única exclusivamente o (.odt)?
e outra,como o autor cita no tópico,o formato é opensource,tu pode analisar ele como tu bem entender
-
Para mim, esta é uma discussão bastante simplista. O problema não está no formato do pacote, se RPM, DEB, TGZ, TAR.GZ.PKG, etc. Como foi dito acima, se duas versões do sistema são incompatíveis, não há pacote que resolva. O ramo unstable (Sid) do Debian também usa os mesmíssimos pacotes DEB do ramo estável (Etch), mas os pacotes de cada um deles podem ser incompatíveis simplesmente porque se trata de versões diferentes e pronto! Um Ubuntu lançado em outubro de 2007, com o Gnome 2.20, não será compatível com o Debian Etch, que foi lançado no início deste ano, ainda com o Gnome 2.16! E o problema das dependências: uma distro menos focada no conforto pode até mesmo aceitar o controle de dependências (com a instalação automática das mesmas), mas é bem possível que o pessoal do Slackware, por exemplo, acredite que o mesmo programa exija muito menos dependências que o pessoal do Ubuntu atribuiria ao mesmo. E o tipo de pacote - DEB, RPM ou TGZ, - tem muito pouco a ver com isto.
veja o caso do autopackage.
http://www.autopackage.org/
estes pacotes vão instalar tanto no meu ubuntu,quando no gentoo do meu amigo,quando no fedora,slack,etc.
distribuições totalmente diferentes! (ou você acha que não?) funcionam! o que ocorre é que você esta comparando deb,rpm,.tar.gz (puts da pra ve que tu não entende nada ao comparar o .tar.gz)
como eu ja disse trilhões de vezes. o deb,rpm,são pacotes diferentes... sem a POSSIBILIDADE de se fazer um pacote multi-distro.
eles só pegam os binários dentro do pacote,e colocam a pasta especificada de instalação. o que mais ele faz é verificar as dependências. não tem INTERFACE GRÁFICA!,NÃO TEM COMO PEDIR SERIAL OU ATÉ MESMO O LOCAL A INSTALAÇÃO.comparar um rpm e um deb por não funcionarem em varias distros é totalmente sem cabimento.
o que vocês pensam é que seria só um pacote como um rpm ou deb e se renomeia para algum outro nome e pronto,se fosse isso ninguém iria estar perdendo tempo aqui. a questão é que o pacote tem que ser como um autopackage desenvolvido pelas distros,é possível sim funcionar em qualquer distro basta ter a coperação entre eles
é obvio que pode ter problemas que alguns programas não funcionem em todas as distros. se tu faz um programa para interagir com o gnome e tu não tem gnome não irá funcionar,é obvio! mesma coisa que tu criar um jogo para rodar o som em ALSA e a distro só aceita OSS.
a questão é que hoje em dia com rpm,deb,etc nem se tu tem todos os componentes da mesma versão irá funcionar de uma para outra distro,com uma padronização claro que iria funcionar se a distro estivesse com os requisitos especificados pelo padrão
O que muitos não percebem é que a única forma que o Windows encontrou de resolver o problema foi tornar cada uma de suas versões totalmente compatível com as outras. Mas isto sempre deu tanto trabalho ao desenvolvimento deste sistema que terminou sendo parcialmente abandonado pelo Vista: muitos executáveis do XP simplesmente não funcionam no Vista, exatamente, aliás, como boa parte dos pacotes do Debian Sid não funciona no Etch.
uma coisa que vejo que tu não tem idéia do que fala é que os programas do windows,em 98% dos casos não é um pacote instalador,e sim pura e simplesmente um executável,pois o windows não tem variantes irá funcionar sempre,se tu tem winxp,compilar para ele o outro que tiver vai rodar também.
o kernel do xp pro vista teve uma mudança completa.isso faz com que o sistema não tenha compatibilidade, o que no caso do linux.tu vai criar o programa para o kernel 2.6 em muitos casos até para 2.4 em diante. o kernel não se modificou todo a esse ponto,a maioria das distros usa o 2.6 (uns 95% pelomenos)
um pacote instalador não é um executável,ou você achava que os (.exe) do windows erão pacotes?
Portanto, a existência de um pacote padrão dificilmente resolveria o problema da incompatibilidade entre distros distintas. Os pacotes adequados a uma distro que privilegia a atualidade dos programas (como a Arch, Ubuntu, etc.) seriam sempre incompatíveis com aqueles outros de uma distro que privilegia a estabilidade (como o Debian, Slackware, etc.). E é bom que isto continue assim.
explique-me o porque os programas em autopackage funcionam em muitas distros,sem edições nem uma?
ou intão os programas com (.bin) e os (.run) vou citar alguns:
IBM Symphony
Unreal Tournament 2004
Doom3
etc.
realmente devo estar bêbado esses programas não existem...
Desse modo, se todas adotassem o RPM, ainda assim haveria a necessidade de um RPM para a Suse, outro para a Fedora, outro para a Yoper e assim por diante. A vida só ficaria fácil mesmo para o desenvolvedor, que teria que aprender a empacotar apenas no formato RPM. Não sei se é uma vantagem que vale a pena, ante os prejuízos sofridos pela natural diversidade do mundo Linux.
como eu disse o RPM seria impossivel de se fazer qualquer coisa deste modo,o que ocorre,é que vocês não leem todo o tópico vem na ultima pagina sem entender nada e ficam falando umonte de abobrinha
Mas, o que esta debate revela de modo flagrante, ao meu ver, é que tem muita gente usando Linux com a cabeça no Windows.
sem comentários.....
Komodor,
Sua observação a respeito do meu "nada entender" pelo fato de citar o tar.gz só revela que sua leitura é desatenta. Eu citei, não o TAR.GZ e sim o TAR.GZ.PKG, que é o pacote binário da Arch. Seja mais atento e mais educado, sim. Não é preciso desqualificar a pessoa de quem se discorda, mas apenas refutar o seu argumento em si mesmo.
E o que você não entende ao citar o autopackage é a redundância que ele acaba gerando. O autopackage só funciona em todas as distros porque cada pacote instala por padrão todas as suas dependências, independentemente do que já existe no sistema. Logo, ao instalar vários pacotes destes no seu sistema você terá em pouco tempo um bocado de bibliotecas e programas redundantes (vale dizer, duas ou três bibliotecas e programas em diferentes versões, pois é esta a razão do "milagre" do mesmo pacote funcionar num Slackware e na Arch Linux). Não há milagres no que respeita a este problema, meu caro. O que se ganha de um lado, se perde de outro. A questão é que você só percebe - empiricamente - que o autopackage funciona em qualquer sistema, sem perguntar-se porque isto acontece. É ao ir mais a fundo que se percebe os poréns desta proposta.
*-*-*-*-*
Se você der uma olhadinha neste ligeiro tutorial sobre o autopackage http://www.guiadohardware.net/tutoriais/dominando-autopackage/ (http://www.guiadohardware.net/tutoriais/dominando-autopackage/), você verá que o autor diz claramente:
Ele (o autopackage)foi criado para instalar apenas programas não-essenciais, como processadores de texto, navegadores, jogos e outros, já que para pacotes essenciais, é recomendável o uso do sistema nativo, para melhor velocidade e compatibilidade.
E por que é recomendável o uso do sistema nativo em relação aos programas essenciais? Bem, o próprio autor o diz implicitamente, ao afirmar que o o Autopackage verifica a presença de dependências no computador, bem como examina as informações do pacote, e isso reduz a incompatibilidade entre diferentes padrões de distribuições.
Reduz, não supera.
No tópico dedicado ao tema na Wikipedia também se afirma que Autopackage se diferencia de otros sistema de instalación como Loki installer en que Autopackage está especialmente diseñado para ser compatible con tantas distribuciones como sea posible.
Vale dizer, não é verdade que se trata de um instalador realmente universal. Quanto mais ampla for a compatibilidade do autopackage maior será o tamanho dos respectivos pacotes, pois maior será a quantidade de dependências a serem instaladas por padrão.
Em outras palavras, o autopackage pode ser perfeitamente adequado para permitir, por exemplo, que um aplicativo não-essencial e menos dependente das bibliotecas básicas do sistema seja instalado sem maiores problemas. Seria muito conveniente, aliás, que programas como Opera, Frostwire, Exaile e Amule, dentre outros, sempre tivesse um package disponível em seus sites na Internet. Mas eu sou muito cético quanto a possibilidade dele ser gerenciador de pacotes padrão de qualquer distro.
Exemplo disso é o PC-BSD, cujos pacotes secundários são oferecidos na forma de PBIs. Bem os PBIs são apenas uma adaptação do autopackage, funcionando da mesmíssima forma, ou seja, através de simples scripts em bash (pois cada package não passa de um script em bash a qual são somadas diferentes interfaces gráficas). Ora, todo o sistema (que não passa de um FreeBSd pré-configurado) é construído através do tradicional sistema de ports do BSD, com seus próprios pacotes TGZ. Só alguns poucos pacotes suplementares estão disponíveis na forma de PBI, quase nada se comparado a base do sistema.
Portanto, eu nada tenho contra o autopackage. Até acho que ele é uma proposta bem interessante, que poderia ser melhor e mais usado. Mas, nem de longe, o considero adequado como um sistema de gerenciamento de pacotes padrão. Aliás, acho muito discutível que o tal "sistema de gerenciamento de pacotes padrão" seria realmente necessário. Mas, se for o caso, acho que há candidatos muito melhores, como o pacman e, sobretudo, o Conary, que estão léguas à frente do autopackage em sofisticação tecnológica, por menos que eles pareçam com um exe. do Windows.
-
realmente o autopackage não seria uma alternativa viável.
O que não entendo é por que TODAS as distros não usam um único gerenciador de pacotes ?
se o .rpm é o tipo padrão, por que o debian, ubuntu, não usam ele ?
eu sei que o debian tem certas frescuras sobre licensa, etc.. Então por que eles não criam gerenciador de pacotes universal e se necessário , adaptam suas distros para esse novo gerenciador de pacotes.
não vejo motivo que dificulte essa criação.
-
E o que você não entende ao citar o autopackage é a redundância que ele acaba gerando. O autopackage só funciona em todas as distros porque cada pacote instala por padrão todas as suas dependências, independentemente do que já existe no sistema. Logo, ao instalar vários pacotes destes no seu sistema você terá em pouco tempo um bocado de bibliotecas e programas redundantes (vale dizer, duas ou três bibliotecas e programas em diferentes versões, pois é esta a razão do "milagre" do mesmo pacote funcionar num Slackware e na Arch Linux). Não há milagres no que respeita a este problema, meu caro. O que se ganha de um lado, se perde de outro. A questão é que você só percebe - empiricamente - que o autopackage funciona em qualquer sistema, sem perguntar-se porque isto acontece. É ao ir mais a fundo que se percebe os poréns desta proposta.
pelo que me lembro o tópico não é para deixar o autopackage como padrão e sim criar um novo formato que pode (veja bem,eu disse pode) usar a base do autopackage.
um negocio que você não entende de forma alguma é que eu sempre frizei que o autopackage não esta pronto e usei ele de referencia para o que você dizia ser impossível,que pelo que vejo teve que analisar meus argumentos só agora viu que existe um modo que realmente funciona,pois naquela argumento eu não havia mensionado que o autopackage era perfeito...
a questão de funcionar é mais que obvia que funciona(que você dizia não ser possível),a questão das dependências é uma das principais necessidade de se criar um novo formato que possa integrar o sistema nativo de pacotes (como o apt) para solucionar esses problemas.
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
Se você der uma olhadinha neste ligeiro tutorial sobre o autopackage http://www.guiadohardware.net/tutoriais/dominando-autopackage/ (http://www.guiadohardware.net/tutoriais/dominando-autopackage/), você verá que o autor diz claramente:
Ele (o autopackage)foi criado para instalar apenas programas não-essenciais, como processadores de texto, navegadores, jogos e outros, já que para pacotes essenciais, é recomendável o uso do sistema nativo, para melhor velocidade e compatibilidade.
E por que é recomendável o uso do sistema nativo em relação aos programas essenciais? Bem, o próprio autor o diz implicitamente, ao afirmar que o o Autopackage verifica a presença de dependências no computador, bem como examina as informações do pacote, e isso reduz a incompatibilidade entre diferentes padrões de distribuições.
Reduz, não supera.
porque tu acha que digo sempre que o autopackage não está pronto ainda? pois se esse pacote fosse integrado ao sistema nativo do sistema,não haveria como isso ocorrer ai que necessita de um NOVO pacote e com a colaboração dos desenvolvedores!! para que o pacote pudesse ter uma integração grande com os diversos tipos de sistemas nativos (ai o porque do padrão)
No tópico dedicado ao tema na Wikipedia também se afirma que Autopackage se diferencia de otros sistema de instalación como Loki installer en que Autopackage está especialmente diseñado para ser compatible con tantas distribuciones como sea posible.
Vale dizer, não é verdade que se trata de um instalador realmente universal. Quanto mais ampla for a compatibilidade do autopackage maior será o tamanho dos respectivos pacotes, pois maior será a quantidade de dependências a serem instaladas por padrão.
é como eu respondi nos 2 quotes anteriores. sobre a integração do sistema nativo e necessitando a ajuda dos desenvolvedores da distribuição... por isso o autopackage não esta pronto!!
Em outras palavras, o autopackage pode ser perfeitamente adequado para permitir, por exemplo, que um aplicativo não-essencial e menos dependente das bibliotecas básicas do sistema seja instalado sem maiores problemas. Seria muito conveniente, aliás, que programas como Opera, Frostwire, Exaile e Amule, dentre outros, sempre tivesse um package disponível em seus sites na Internet. Mas eu sou muito cético quanto a possibilidade dele ser gerenciador de pacotes padrão de qualquer distro.
ele não vai substituir nada,ele só vai acrescentar (é pela 300º que falo isso...),o objetivo do padrão de pacotes é para integrar o gerenciador de pacotes padrão do sistema (como o apt) ou seja você vai continuar com o apt funcionando perfeitamente e quando o pacote precisar de alguma dependências ele vai mandar o apt instala-las
Exemplo disso é o PC-BSD, cujos pacotes secundários são oferecidos na forma de PBIs. Bem os PBIs são apenas uma adaptação do autopackage, funcionando da mesmíssima forma, ou seja, através de simples scripts em bash (pois cada package não passa de um script em bash a qual são somadas diferentes interfaces gráficas). Ora, todo o sistema (que não passa de um FreeBSd pré-configurado) é construído através do tradicional sistema de ports do BSD, com seus próprios pacotes TGZ. Só alguns poucos pacotes suplementares estão disponíveis na forma de PBI, quase nada se comparado a base do sistema.
nunca usei BSD,não posso falar do que eu nunca mexi.... pelo que entendi você quis fazer uma comparação sendo que esse tal de PBI seria o autopackage e os pacotes padrões que são os TGZ.
e que os PBI quase não são usados.
se esse tal de PBI realmente é como você fala que é uma adaptação do autopackage deve cair no mesmo ponto de os desenvolvedores não darem bola,mas eu não tenho idéia de como realmente funciona.
não sei porque citou o PC-BSD,mas se você se refere como tudo parecido intão que faça exemplos em sistemas que falamos e temos contatos (linux)
Portanto, eu nada tenho contra o autopackage. Até acho que ele é uma proposta bem interessante, que poderia ser melhor e mais usado. Mas, nem de longe, o considero adequado como um sistema de gerenciamento de pacotes padrão. Aliás, acho muito discutível que o tal "sistema de gerenciamento de pacotes padrão" seria realmente necessário. Mas, se for o caso, acho que há candidatos muito melhores, como o pacman e, sobretudo, o Conary, que estão léguas à frente do autopackage em sofisticação tecnológica, por menos que eles pareçam com um exe. do Windows.
como eu respondi em todos os quotes,o autopackage não esta pronto eu só citei ele porque você disse NÃO ser possível aplicativos que funcionassem em multi-distro.
o padrão ele chamaria o gerenciador de pacotes nativo (por exemplo o apt) e trabalharia junto com ele e não só.
o padrão de que agente se refere é que a distribuição esteja com tais requisitos suprido,e que as ferramentas nativas da distro estejam prontas para trabalharem com o pacote,você NÃO vai para de usar o seu sistema nativo,até porque isso teria que mudar toda a base do sistema e isso é como menciono desdo inicio,não é assim! ele irá trabalhar junto,como uma ferramenta adicional.
-
realmente o autopackage não seria uma alternativa viável.
O que não entendo é por que TODAS as distros não usam um único gerenciador de pacotes ?
se o .rpm é o tipo padrão, por que o debian, ubuntu, não usam ele ?
eu sei que o debian tem certas frescuras sobre licensa, etc.. Então por que eles não criam gerenciador de pacotes universal e se necessário , adaptam suas distros para esse novo gerenciador de pacotes.
não vejo motivo que dificulte essa criação.
mas ai que esta amigo,tudo se torna complicado pois mesmo que fosse escolhido só um formato como um rpm ou deb não adiantaria por diversos motivos e a criação de um pacote universal seria exatamente o que proponho. infelizmente não irei lhe explicar o porque não bastaria todos adotar um rpm ou deb, pois é muitos detalhes,que nos estivemos discutindo ao longo deste tópico.
recomendo que você leia o tópico na integra para entender melhor.
grato
-
Não sei se pode servir de exemplo ou referência...
Mas como sabem, o MAC OSX é baseado no freeBSD (SO "unix like") e tem um sistema de gestão de aplicações. Não me lembro de ouvir ou ler queixas dos seus utilizadores sobre esse sistema de gestão de aplicativos.
Penso que as aplicações disponibilizadas por terceiros para o OSX, são disponibilizadas num formato padronizado para este SO.
Não sei como funciona o sistema no que refere a gerir dependências, incompatibilidade de versões, etc
Mas certamente, poderá haver alguma coisa a aprender com a solução adoptada pela Apple.
Mais info:
http://www.apple.com/macosx/features/unix/
-
Não conheço o sistemas de empacotamento do Mac, mas visto o número de fanboys da empresa, ele nem precisa ser bom, já que eles (e não somente) idolatram qualquer coisa que a Apple lance no mercado.
-
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.
-
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.
-
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? :]
-
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.
-
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.
-
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.
-
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.
-
"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 ;)
-
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"
-
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?
-
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
-
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.
-
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.
-
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....
-
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 ;)
-
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 ;)
realmente tenho exagerado em várias respostas.me desculpem a todos por deixar este tópico a um nivel desses
o que ocorreu que me deixou assim foi nas primeiras paginas se você prestar atenção,alguns usuários simplesmente chegando sem ler o todo o tópico.e dando a entender que eu era simplesmente um imbecil
dizendo que era impossível,ou que era uma manifestação idiota de um usuário windows. não chegando diretamente com essas palavras mas tentando de tudo que forma dizer isso. sendo que os argumentos erão sem cabimentos e com falta de respeito,acabei me elevando.
pode ver estamos na 6º pagina,em todos os meus tópicos mantive sempre o interesse por responder as duvidas,sem que as minha mensagens são enorme com fim de que seja esclarecido tudo. o pessoal simplesmente não lê,muitas vezes não lê nem o artigo que eu mencionei,não entendem e querem dizer que estou falando coisas idiotas,ai é que esta.as vezes agente fica um pouco mais alterado.
como no caso de um usuário que no começo começou me acusando por tópico ser totalmente infundado e sem sentido,por tópico ser totalmente "sem pé nem cabeça" e que eu estava "usando linux com a cabeça no windows",francamente,esses comentários respondo a nível de quem fez a pergunta.depois ele começou a ficar menos agressivo com suas respostas e eu menos com as minhas em relação a ele.
mais uma vez peço desculpas a quem ficou pensando que sou simplesmente um ser tremendamente arrogante. levarei isso em conta e irei mudar com quem me respeita,(claro se alguém mandar uma resposta dando indiretas e não quiser respeitar,esse certamente de mim não terá respeito com a mensagem que irei responder)
-
você sempre discorda mas parece que certos argumentos tu sempre faz questão de não ler,interessante..
Eu não acho tais argumentos relevantes, por mais que você insista em repeti-los. Eles nem pertencem ao foco da questão! Infelizmente, como já foi dito anteriormente, você não consegue debater com serenidade e por esta razão, encerro aqui a minha participação neste tópico. A pretensa indispensabilidade do pacote padrão não é uma questão pessoal e se você não consegue entendê-lo, é bom deixar o debate para mais tarde.
-
Resumo da discussão até aqui (acho que estamos chegando a um consenso):
-Padronização não é interessante num modelo como o do software livre, até porque cada tipo de pacote e de gerenciador tem suas vantagens e desvantagens.
-Contudo, seria interessante se projetos como o autopakage fossem mais valorizados pelos desenvolvedores em geral. Assim, baixar e instalar um programa a partir de seu site oficial se tornaria bem mais simples.
-E com isso, até o trabalho dos desenvolvedores iria diminuir, pois não teriam mais que compilar um pacote diferente para cada distro.
-----------------------
Padronização NÃO!
Autopakage-likes SIM!
-
Sou a favor de uma árvore de diretórios comum à todas as distribuições e tambem uma opção universal para instalação de pacotes.
Isso não feriria de forma alguma a liberdade dos usuários.
-
...
Padronização NÃO!
...
É curioso ler uma coisa destas.
É precisamente o caminho da adopção de padrões que tem garantido o sucesso de muitos projectos do software livre. Só para recordar: Firefox, no que refere ao seguimento dos padrões web; OpenOffice, sendo a aplicação de escritório de referência quando se fala em ODF (um padrão para documentos).
A iniciativa FreeDesktop.org é outro exemplo que visa a interoperabilidade de diferentes sistemas GUI e veio trazer ordem ao caos que exista há alguns anos. Lembram-se?
É um exemplo muito bom de que a existência de padronização e regras não são restritivas nem limitadoras e vem trazer muitos benefícios aos utilizadores.
Há uns 7 ou 8 anos atrás eu comentava com amigos e colegas que a única forma de aplicações tipo Office livres terem sucesso, seria adoptarem formatos que fossem suficientemente apelativos e compatíveis com uma multiplicidade de ambientes e plataformas. Era a única forma de tentar destronar os formatos da m$. Ninguém concordava comigo e até troçavam defendendo que a única solução seria seguir a m$ e os seus formatos fechados (havia quem lhe chama-se padrão).
O que apareceu entretanto (Oásis, ODF) é algo parecido com o que eu defendia.
Actualmente as organizações e governos mais conscientes da importância do uso de padrões, estão a exigir fornecimentos de fornecedores que obedeçam a padrões. Foi esse um dos motivos que fez a microsoft ir ás pressas forçar a aprovação como padrão de um formato proprietário e restrito:o OOXML
É preciso repensar um pouco melhor as coisas e perceber que o uso de padrões em nada é restritivo da liberdade. Nem mesmo quando falamos de mecanismos que padronizem a instalação de aplicações.
Temos que estar preparados para o futuro. A microsoft tem uma patente referente á instalação de componentes de software por módulos, que é qualquer coisa como: um sistema base (possivelmente gratuito) pode ser expandido pela aquisição de pequenos componentes de software (por via electrónica) que estendem o sistema base. A m$ está atenta ao futuro de tem na manga soluções alternativas ao modelo que usa nos dias de hoje.
A antecipação do mundo do software livre na criação e divulgação de um modelo padrão de distribuição de aplicações, é um passo em frente e muito importante. É estratégico definir modelo que possa ser aprovado como padrão (iso ou outro). Isso seria um passo de enorme antecipação.
Este padrão pode mesmo passar por vários "níveis" ou tipos de empacotamento de software. Isto para poder garantir a co-existência de sistemas diferenciados.
Assim, um produtor de software em vez de ter de disponibilizar um pacote para 101 distros diferentes, assumiria apenas a necessidade de criar 5 tipos de empacotamento. O sistema de gestão de pacotes, saberia distinguir qual usar.
Há alguns anos atrás assisti ao surgimento do Lindows (actual Linspire). A maior novidade desse sistema (para mim), era a adopção de um sistema de distribuição de aplicações chamado click'n'run (ou algo parecido). Olhei para isso como algo absolutamente inovador e que deveria ser seguido por outras distros. É esse tipo de facilidades atrai clientela para o linux.
edit: correção do "copy paste" com a inclusão do FreeDesktop.org
-
alexcunha,
Eu recomendo que você leia o restante do tópico, mesmo que muito extenso e algumas vezes redundante, pois os seus argumentos já foram apresentados e também já foram contestados.
Mas, basicamente, é preciso entender: rpm, deb, tgz...; apt, urpmi, yum, conary...; cada um desses sistemas de pacotes e de gerenciamento tem suas vantagens e desvantagens. Não há nenhum perfeito ou totalmente superior aos outros. Portanto eleger um único sistema de gerenciamento é sim restringir a liberdade de escolha.
No entanto, isso não impede que se tenha um sistema de empacotamento universal, paralelo a esses - um exemplo ilustrativo é o autopakage -, que facilitasse as instalação de programas avulsos baixados na internet. Mas, nesse caso, a liberdade de cada distro, para escolher o sistema de empacotamento que lhe pareça mais adequado, é mantida.
Por tudo isso eu repito:
Padronização NÃO!
Opção de pacote universal SIM!
-
Gabriel,
A definição e eleição de um padrão, não significa o abandono e rejeição dos métodos que já existem.
A padronização seria um passo em frente e certamente demoraria algum tempo a ser definido.
E quando me refiro a padronização, não falo de uma padronização iso mas sim de uma base de entendimento aceite por um consórcio - inicialmente um grupo restrito de distribuições e inevitavelmente aceite e adoptada pelas restantes.
Veja-se o exemplo do FreeDesktop.org (por lapso não incluí parte do texto, mas já corrigi).
-
um consórcio - inicialmente um grupo restrito de distribuições e inevitavelmente aceite e adoptada pelas restantes.
alexcunha,
Esse é o modelo Microsoft de desenvolvimento: "Impor padrões independentemente da qualidade e das necessidades de cada caso".
Não interessa como se dê o processo de padronização, as consequências disso é que seriam nocivas.
Entenda, há grupos que preferem "rpm", outros "deb". Outros ainda, preferem deb+apt enquanto um novo grupo prefere deb+conary. E todos estes têm ótimos argumentos pras suas escolhas.
Ser obrigado a usar um único tipo de empacotamento porque as principais distros usam, é ter a liberdade de escolha restringida.
Por isso a única solução viável seria ter um sistema de pacotes universal em paralelo aos que já existem, e que não modificasse em nada a estrutura atual das distros.
-
Desculpa, Gabriel, mas acho que agora quem não está entendendo é você. 1) Ninguém está falando em impor padrões. Se o metro é padrão no sistema internacional, isso não impede de muitos países preferirem medir em polegadas. Da mesma forma, não se está obrigando nenhuma distro a abandonar seus pacotes já instaurados, apenas que também aceitem um outro tipo de pacote, ainda que isso custe mais implementação para o sistema. 2) Também não podemos dizer que a MS impõe padrões (a não ser no caso do OOXML), por dois motivos: a) a MS sempre foi absoluta no mercado, o que, na prática, implica dizer que o doc sempre foi padrão DE USO; é uma questão de domínio de mercado; b) nada na MS é padrão DE FATO, porque um padrão deve ser aberto (como o metro poderia ser padrão se não fosse divulgada a sua exata medida?). Agora que o uso do ODF está crescendo, nasce junto a necessidade de se ter um padrão DE FATO, já que agora as pessoas têm possibilidade de escolha, e foi por isso que a ISO entrou na estória. Não podemos, portanto, dizer que a MS impõe padrões porque eles simplesmente não existiam, eram apenas (como ainda são) extensões proprietárias, fechadas. Agora pense no seguinte: depois da aprovação do ODF como padrão, a ISO obrigou a MS a padronizar o Word? Não, porque o programa é uma coisa, a extensão é outra; a ISO obrigou a MS a fazer o Office salvar apenas em ODT? Também não. De modo análogo, no caso do padrão de pacotes, nenhuma distro será obrigada a ficar igual a outra e nem a adotar o pacote universal como o SEU pacote de funcionamento. É claro que o ODT teve que ser incluído no Office 2007, porque a MS não deixaria de implementar o padrão de fato -- embora pudesse deixar de fazê-lo; da mesma forma, um pacote padrão teria que ser incluído nas distros -- a não ser que se não quisesse.
Agora, eu entendo a preocupação e os argumentos de todos vocês (principalmente no que se refere a dificuldade de implementação), tanto é que já me posicionei a respeito: se não for possível um pacote padrão (o que, repito, não quer dizer que seria obrigatório), acho que, pelo menos, deve-se facilitar o processo.
Entenda, Gabriel, eu não estou indo de encontro aos seus argumentos (ao menos acho que não). Só acho que você tem distorcido um pouco essa estória de padrões.
-
1) Ninguém está falando em impor padrões.
Vinícios,
Alguns no tópico estão falando em impor padrões sim, e no sentido que eu coloquei. Foi para os que têm essa opinião que eu escrevi o meu post.
Na verdade, pelo que vi, sua opinião e bastante próxima da minha, que é:
Seria interessante que os desenvolvedores empacotassem seus programas avulsos - distribuídos em seus sites oficiais - em um modelo que chegasse próximo da universalidade, como autopakage, ".bin" ou ".run".
Mas que isso não interfira na liberdade de cada distro de usar o sistema e o gerenciador de pacotes que melhor lhes convier.
-
---------------------------------///------------------------------
Eu não acho tais argumentos relevantes, por mais que você insista em repeti-los. Eles nem pertencem ao foco da questão! Infelizmente, como já foi dito anteriormente, você não consegue debater com serenidade e por esta razão, encerro aqui a minha participação neste tópico. A pretensa indispensabilidade do pacote padrão não é uma questão pessoal e se você não consegue entendê-lo, é bom deixar o debate para mais tarde.
imagina,nem pertence,sendo que os programas em que nos referimos para a criação do padrão é mais especifico aos projetos fechados (não só mas,eles seriam um alvo maior) a maioria é (.run) e (.bin) realmente,esse meu argumento não faz sentido para você,como todo o tópico,a questão é: se esse tópico e indispensável porque veio argumentar? realmente não consigo compreende-lo.
de qualquer forma ninguém esta lhe obrigando a participar deste tópico
---------------------------------///------------------------------
Resumo da discussão até aqui (acho que estamos chegando a um consenso):
-Padronização não é interessante num modelo como o do software livre, até porque cada tipo de pacote e de gerenciador tem suas vantagens e desvantagens.
-Contudo, seria interessante se projetos como o autopakage fossem mais valorizados pelos desenvolvedores em geral. Assim, baixar e instalar um programa a partir de seu site oficial se tornaria bem mais simples.
-E com isso, até o trabalho dos desenvolvedores iria diminuir, pois não teriam mais que compilar um pacote diferente para cada distro.
-----------------------
Padronização NÃO!
Autopakage-likes SIM!
(1º) - claro que tem suas vantagens e desvantagens,mas a questão é que os sistemas nativos não tem varias coisas que são estritamente necessárias principalmente para quem vende software,como por exemplo perguntar aonde quer salvar,pedir serial,etc (aquelas coisas que citei varias vezes durante este tópico
(2º) - se for para que os desenvolvedores das distribuições ajudem a melhorar para chegar a um ponto ótimo em que possa ser utilizado por todos sem perdas é isso o que estamos propondo até agora,que pode pegar a base do autopackage e fazer um com a ajuda dos desenvolvedores das distribuições,mas se for para pegar o autopackage assim do jeito que esta então que continuemos do jeito que estamos pois ele tem muitos problemas ainda,como citei quando o piras achava que eu estava querendo que o autopackage fosse o padrão
(3º) - é esse o objetivo do padrão,mas com o autopackage assim,sem a ajuda dos desenvolvedores é preferivel ficar do jeito que estamos hoje,pois ele não é uma boa escolha,pois tem alguns problemas de compatibilidade porque as distribuições não se unem para fazer,dai nada ficará multi-distro decentemente.
amigo pelo que entendi você esta com a idéia de que padrão é uma imposição,uma obrigação.que deve ser usada para todos em todos os casos e não é isso não.o padrão ele deve ajudar o sistema nativo de pacotes. (ou seja o sistema nativo vai ficar).as distribuições que não quiserem esse padrão então eles não seguem e ponto final.a questão é que as distribuições que seguirem vão ter a opção de usar o sistema nativo e mais o padrão.
padrão não é obrigação.
---------------------------------///------------------------------
alexcunha,
Eu recomendo que você leia o restante do tópico, mesmo que muito extenso e algumas vezes redundante, pois os seus argumentos já foram apresentados e também já foram contestados.
Mas, basicamente, é preciso entender: rpm, deb, tgz...; apt, urpmi, yum, conary...; cada um desses sistemas de pacotes e de gerenciamento tem suas vantagens e desvantagens. Não há nenhum perfeito ou totalmente superior aos outros. Portanto eleger um único sistema de gerenciamento é sim restringir a liberdade de escolha.
No entanto, isso não impede que se tenha um sistema de empacotamento universal, paralelo a esses - um exemplo ilustrativo é o autopakage -, que facilitasse as instalação de programas avulsos baixados na internet. Mas, nesse caso, a liberdade de cada distro, para escolher o sistema de empacotamento que lhe pareça mais adequado, é mantida.
Por tudo isso eu repito:
Padronização NÃO!
Opção de pacote universal SIM!
amigo não querendo ser chato,mas não é bem assim,você não deve ter lido muito bem certas respostas. pois quando você se refere "Portanto eleger um único sistema de gerenciamento é sim restringir a liberdade de escolha.",seguinte ninguém vai eleger um sistema que irá substituir o sistema padrão normal (como no caso o apt),ele vai se integrar com ele e em HIPÓTESE ALGUMA será obrigado a substituir,tando é que eu sempre falo que o sistema de updates etc,será sempre utilizando o sistema nativo da distribuição.e não este padrão.
e como eu disse esses rpm,deb,etc não podem ser comparados pois eles na maioria dos casos de softwares fechados,não o utilizam,é muito pouco a utilização deles,pois não tem muitas coisas necessarias é exatamente por isso que utilizam os (.bin) e (.run).alem de que há um possibilidade de deixar ele funcionando em varias distros(sendo que não existe padrão,então certamente em muitas distro vai haver muitos problemas)
uma opção de pacotes universal sem padrão é como o autopackage de hoje,se cada uma distribuição só pensar em fazer um pacote "universal" para si,ai nada vai funcionar direito.e pra isso que tem o padrão.
repetindo mais uma vez: padrão não é obrigação!
---------------------------------///------------------------------
um consórcio - inicialmente um grupo restrito de distribuições e inevitavelmente aceite e adoptada pelas restantes.
alexcunha,
Esse é o modelo Microsoft de desenvolvimento: "Impor padrões independentemente da qualidade e das necessidades de cada caso".
Não interessa como se dê o processo de padronização, as consequências disso é que seriam nocivas.
Entenda, há grupos que preferem "rpm", outros "deb". Outros ainda, preferem deb+apt enquanto um novo grupo prefere deb+conary. E todos estes têm ótimos argumentos pras suas escolhas.
Ser obrigado a usar um único tipo de empacotamento porque as principais distros usam, é ter a liberdade de escolha restringida.
Por isso a única solução viável seria ter um sistema de pacotes universal em paralelo aos que já existem, e que não modificasse em nada a estrutura atual das distros.
amigo,este padrão que nos estamos propondo NUNCA substituirá os sistemas nativos (sim! eu disse nunca!),ele vem para implementar,ele irá ajudar o sistema nativo.se você usa rpm você vai continuar usando o rpm junto com o padrão,se você usa o deb,você continuara usando deb junto com o padrão
sendo que você vai continuar usando o sistema original mais o padrão,não é restrição na liberdade pois afinal.você vai continuar usando seu sistema nativo qual seja ele.
padrão frizo mais uma vez: padrão não é obrigação.
o odf é um padrão,por isso os suite offices de hoje são obrigados a usarem só o odf? (perai o M$ office nem suporta oficialmente esse padrão)
---------------------------------///------------------------------
1) Ninguém está falando em impor padrões.
Vinícios,
Alguns no tópico estão falando em impor padrões sim, e no sentido que eu coloquei. Foi para os que têm essa opinião que eu escrevi o meu post.
Na verdade, pelo que vi, sua opinião e bastante próxima da minha, que é:
Seria interessante que os desenvolvedores empacotassem seus programas avulsos - distribuídos em seus sites oficiais - em um modelo que chegasse próximo da universalidade, como autopakage, ".bin" ou ".run".
Mas que isso não interfira na liberdade de cada distro de usar o sistema e o gerenciador de pacotes que melhor lhes convier.
amigo não sei de quem você se refere de que esta falando que estão querendo impor padrões,caso estivesse pensando que fosse eu que tivesse essa intenção peço desculpas,pois esse em hipótese alguma foi a minha idéia,tanto é que eu sempre defendi que o sistema nativo trabalhasse com o padrão e em nem um caso é obrigado.alias o padrão ele necessita trabalhar junto com o sistema nativo.
é exatamente a idéia mesmo,o padrão ele vem como uma ajuda a mais,para que não fiquem criando vários pacotes "universais" que na verdade só funcionam naquela distro.e que você que escolhe se quer ou não seguir o padrão pois nada é obrigatório.
seria uma opção a mais,e que as distribuições tratariam esse pacote da mesma forma,junto com seu sistema nativo,e certamente se você usar a distribuição que tem o sistema nativo deb e o padrão,você escolherá qual deles usar,se você preferir criar em deb ou o padrão ou até mesmo em ".bin" ou ".run",a escolha é toda sua
-
Gabriel,
Eu não falo em impor padrões. Se não fui claro, eu defendo uma alternativa ao caos reinante.
Sim, caos. Essa é a percepção de um utilizador leigo.
Achas que o padrão ODF é uma imposição? Achas que o FreeDesktop.org é uma imposição?
O que defendo, é dispor de uma alternativa que tenha condições para ser amplamente utilizada por todos com facilidade de uso, interoperabilidade, com benefício para todos. E ao mesmo tempo, manter outras opções, claro.
E porque não considerar aquilo a que afinal chamas "sistema de pacotes universal" um padrão de fornecimento e instalaçao de aplicações?
Cada distribuição poderia implementar a interface de uso que desejar. No entanto, os processos de deploy (publicação de software) e obtenção e instalação de software, estaria devidamente definidos segundo um padrão aberto conhecido por todos.
Vamos usar como comparação o ODF. Há pelo menos 3 aplicações que usam o ODF. Cada programa tenta ser melhor que o outro. Haverá clientela para os programas Office mais simples, haverá clientela para os programas Office mais sofisticados. Mas no final, o que importa e que todos conseguem trabalhar com um formato padrão de documentos. E a liberdade de escolha mantem-se.
Vou colocar-me agora na posição de utilizador leigo para que entendas melhor
- Não me interessa qual é o sistema melhor (autopakage, rpm, deb, whatever)
- Não quero que, ao encontrar o programa que desejo, verificar que afinal ele é .rpm para a distro XPTO e afinal porque eu uso a distro QWOPT que só suporta .deb, não posso instalar o programa - Isto sim, isto é uma restrição à liberdade!
- Claro que o ponto anterior ser rebatido com a resposta: baixar o source e compilar. Mas quem vai fazer isso, sendo leigo?
- Não quero saber se por estar a usar ubuntu 9.04 não conseguir instalar um .deb que foi feito para ubuntu, 8.10
- Não quero saber de ter de descompactar tar.gz, ./configure, make, make install - mas o que isto?
Entendes-te agora?
Não questiono que é complexo criar um solução para isto. Mas vai ser preciso trabalhar muito sobre isso, claro.
-
Bom, se for assim. Vou me colocar na posição de leigo:
- Qual o sistema no qual posso rodar todos os softwares mais populares?
- Qual o sistema no qual não preciso me preocupar se o hardware que eu comprar vai funcionar ou não?
-Qual o sistema com o qual posso navegar na internet sem me preocupar se a página que quero visitar vai abrir ou não?
É no mínimo ingenuidade achar que coisas como a unificação de pacotes tornarão o Linux mais popular. Como disse num outro tópico, é até divertido participar de discussões como essa, mas isso é completamente inútil. As pessoas usam Windows porque é mais cômodo usar, e é mais cômodo por causa do monopólio. Todos os programas mais populares têm versão para Windows (inclusive os livres ou de códido aberto), todo o hardware do mercado é feito para Windows, a grande maioria das páginas de internet são feitas para usuários de Windows, isso ENTRE OUTRAS COISAS, porque exemplos de como é muito mais cômodo usar Windows do que Linux não faltam. E essa situação não mudará enquanto persistir o monopólio.
E também não adianta espernearem, porque coisas como uma "padronização" nos moldes do que as pessoas querem, ou seja, que as distros sejam todas iguais, que se tenha um único sistema de pacotes, um único ambiente de desktop, uma única biblioteca gráfica, etc., isso nunca acontecerá no Linux. O Linux não PARECE um caos, É. O caos é uma característica do software livre. É assim que sempre foi e sempre será. As pessoas são livres para desenvolver e usar o que elas querem, portanto não é possível impor padrões. É possível apenas sugerir esses padrões, mas não se pode obrigar ninguém a seguí-los.
-
---------------------------------///------------------------------
Eu não acho tais argumentos relevantes, por mais que você insista em repeti-los. Eles nem pertencem ao foco da questão! Infelizmente, como já foi dito anteriormente, você não consegue debater com serenidade e por esta razão, encerro aqui a minha participação neste tópico. A pretensa indispensabilidade do pacote padrão não é uma questão pessoal e se você não consegue entendê-lo, é bom deixar o debate para mais tarde.
imagina,nem pertence,sendo que os programas em que nos referimos para a criação do padrão é mais especifico aos projetos fechados (não só mas,eles seriam um alvo maior) a maioria é (.run) e (.bin) realmente,esse meu argumento não faz sentido para você,como todo o tópico,a questão é: se esse tópico e indispensável porque veio argumentar? realmente não consigo compreende-lo.
de qualquer forma ninguém esta lhe obrigando a participar deste tópico
---------------------------------///------------------------------
Resumo da discussão até aqui (acho que estamos chegando a um consenso):
-Padronização não é interessante num modelo como o do software livre, até porque cada tipo de pacote e de gerenciador tem suas vantagens e desvantagens.
-Contudo, seria interessante se projetos como o autopakage fossem mais valorizados pelos desenvolvedores em geral. Assim, baixar e instalar um programa a partir de seu site oficial se tornaria bem mais simples.
-E com isso, até o trabalho dos desenvolvedores iria diminuir, pois não teriam mais que compilar um pacote diferente para cada distro.
-----------------------
Padronização NÃO!
Autopakage-likes SIM!
(1º) - claro que tem suas vantagens e desvantagens,mas a questão é que os sistemas nativos não tem varias coisas que são estritamente necessárias principalmente para quem vende software,como por exemplo perguntar aonde quer salvar,pedir serial,etc (aquelas coisas que citei varias vezes durante este tópico
(2º) - se for para que os desenvolvedores das distribuições ajudem a melhorar para chegar a um ponto ótimo em que possa ser utilizado por todos sem perdas é isso o que estamos propondo até agora,que pode pegar a base do autopackage e fazer um com a ajuda dos desenvolvedores das distribuições,mas se for para pegar o autopackage assim do jeito que esta então que continuemos do jeito que estamos pois ele tem muitos problemas ainda,como citei quando o piras achava que eu estava querendo que o autopackage fosse o padrão
(3º) - é esse o objetivo do padrão,mas com o autopackage assim,sem a ajuda dos desenvolvedores é preferivel ficar do jeito que estamos hoje,pois ele não é uma boa escolha,pois tem alguns problemas de compatibilidade porque as distribuições não se unem para fazer,dai nada ficará multi-distro decentemente.
amigo pelo que entendi você esta com a idéia de que padrão é uma imposição,uma obrigação.que deve ser usada para todos em todos os casos e não é isso não.o padrão ele deve ajudar o sistema nativo de pacotes. (ou seja o sistema nativo vai ficar).as distribuições que não quiserem esse padrão então eles não seguem e ponto final.a questão é que as distribuições que seguirem vão ter a opção de usar o sistema nativo e mais o padrão.
padrão não é obrigação.
---------------------------------///------------------------------
alexcunha,
Eu recomendo que você leia o restante do tópico, mesmo que muito extenso e algumas vezes redundante, pois os seus argumentos já foram apresentados e também já foram contestados.
Mas, basicamente, é preciso entender: rpm, deb, tgz...; apt, urpmi, yum, conary...; cada um desses sistemas de pacotes e de gerenciamento tem suas vantagens e desvantagens. Não há nenhum perfeito ou totalmente superior aos outros. Portanto eleger um único sistema de gerenciamento é sim restringir a liberdade de escolha.
No entanto, isso não impede que se tenha um sistema de empacotamento universal, paralelo a esses - um exemplo ilustrativo é o autopakage -, que facilitasse as instalação de programas avulsos baixados na internet. Mas, nesse caso, a liberdade de cada distro, para escolher o sistema de empacotamento que lhe pareça mais adequado, é mantida.
Por tudo isso eu repito:
Padronização NÃO!
Opção de pacote universal SIM!
amigo não querendo ser chato,mas não é bem assim,você não deve ter lido muito bem certas respostas. pois quando você se refere "Portanto eleger um único sistema de gerenciamento é sim restringir a liberdade de escolha.",seguinte ninguém vai eleger um sistema que irá substituir o sistema padrão normal (como no caso o apt),ele vai se integrar com ele e em HIPÓTESE ALGUMA será obrigado a substituir,tando é que eu sempre falo que o sistema de updates etc,será sempre utilizando o sistema nativo da distribuição.e não este padrão.
e como eu disse esses rpm,deb,etc não podem ser comparados pois eles na maioria dos casos de softwares fechados,não o utilizam,é muito pouco a utilização deles,pois não tem muitas coisas necessarias é exatamente por isso que utilizam os (.bin) e (.run).alem de que há um possibilidade de deixar ele funcionando em varias distros(sendo que não existe padrão,então certamente em muitas distro vai haver muitos problemas)
uma opção de pacotes universal sem padrão é como o autopackage de hoje,se cada uma distribuição só pensar em fazer um pacote "universal" para si,ai nada vai funcionar direito.e pra isso que tem o padrão.
repetindo mais uma vez: padrão não é obrigação!
---------------------------------///------------------------------
um consórcio - inicialmente um grupo restrito de distribuições e inevitavelmente aceite e adoptada pelas restantes.
alexcunha,
Esse é o modelo Microsoft de desenvolvimento: "Impor padrões independentemente da qualidade e das necessidades de cada caso".
Não interessa como se dê o processo de padronização, as consequências disso é que seriam nocivas.
Entenda, há grupos que preferem "rpm", outros "deb". Outros ainda, preferem deb+apt enquanto um novo grupo prefere deb+conary. E todos estes têm ótimos argumentos pras suas escolhas.
Ser obrigado a usar um único tipo de empacotamento porque as principais distros usam, é ter a liberdade de escolha restringida.
Por isso a única solução viável seria ter um sistema de pacotes universal em paralelo aos que já existem, e que não modificasse em nada a estrutura atual das distros.
amigo,este padrão que nos estamos propondo NUNCA substituirá os sistemas nativos (sim! eu disse nunca!),ele vem para implementar,ele irá ajudar o sistema nativo.se você usa rpm você vai continuar usando o rpm junto com o padrão,se você usa o deb,você continuara usando deb junto com o padrão
sendo que você vai continuar usando o sistema original mais o padrão,não é restrição na liberdade pois afinal.você vai continuar usando seu sistema nativo qual seja ele.
padrão frizo mais uma vez: padrão não é obrigação.
o odf é um padrão,por isso os suite offices de hoje são obrigados a usarem só o odf? (perai o M$ office nem suporta oficialmente esse padrão)
---------------------------------///------------------------------
1) Ninguém está falando em impor padrões.
Vinícios,
Alguns no tópico estão falando em impor padrões sim, e no sentido que eu coloquei. Foi para os que têm essa opinião que eu escrevi o meu post.
Na verdade, pelo que vi, sua opinião e bastante próxima da minha, que é:
Seria interessante que os desenvolvedores empacotassem seus programas avulsos - distribuídos em seus sites oficiais - em um modelo que chegasse próximo da universalidade, como autopakage, ".bin" ou ".run".
Mas que isso não interfira na liberdade de cada distro de usar o sistema e o gerenciador de pacotes que melhor lhes convier.
amigo não sei de quem você se refere de que esta falando que estão querendo impor padrões,caso estivesse pensando que fosse eu que tivesse essa intenção peço desculpas,pois esse em hipótese alguma foi a minha idéia,tanto é que eu sempre defendi que o sistema nativo trabalhasse com o padrão e em nem um caso é obrigado.alias o padrão ele necessita trabalhar junto com o sistema nativo.
é exatamente a idéia mesmo,o padrão ele vem como uma ajuda a mais,para que não fiquem criando vários pacotes "universais" que na verdade só funcionam naquela distro.e que você que escolhe se quer ou não seguir o padrão pois nada é obrigatório.
seria uma opção a mais,e que as distribuições tratariam esse pacote da mesma forma,junto com seu sistema nativo,e certamente se você usar a distribuição que tem o sistema nativo deb e o padrão,você escolherá qual deles usar,se você preferir criar em deb ou o padrão ou até mesmo em ".bin" ou ".run",a escolha é toda sua
Komodor,
Que ótimo, você concorda com o que eu coloquei!
Então por que escreveu um "livro" supostamente rebatendo o que eu escrevi, se no final você diz que concorda?
(Eu hein)
--------------------
Eu acho que as expressões que usei - "Autopakage-likes" ou "um exemplo ilustrativo é o autopakage" -, deixam bem claro que eu me referia apenas ao modelo do autopakage, e não ao projeto em si.
-
Komodor,
Que ótimo, você concorda com o que eu coloquei!
Então por que escreveu um "livro" supostamente rebatendo o que eu escrevi, se no final você diz que concorda?
(Eu hein)
--------------------
Eu acho que as expressões que usei - "Autopakage-likes" ou "um exemplo ilustrativo é o autopakage" -, deixam bem claro que eu me referia apenas ao modelo do autopakage, e não ao projeto em si.
sobre escrever muito sou assim,para não deixar muitas duvidas. bem e sobre eu concordar com você,é em termos,da sua ultima mensagem eu concordei e já mostrei como seria caso aquilo fosse assim.
e as mensagens anteriores não teria como concordar pois você não pensava como agora,e era contra o padrão,dai para cada mensagem expliquei tudo,por isso do livro,mas pode perceber.eu não respondi só a sua mensagem.(a do piras também)
off: só uma correção pequena,seria autopackage e não autopakage
-
bem e sobre eu concordar com você,é em termos,da sua ultima mensagem eu concordei e já mostrei como seria caso aquilo fosse assim.
e as mensagens anteriores não teria como concordar pois você não pensava como agora,e era contra o padrão,
A minha opinião foi a mesma em todas as mensagens que escrevi, você não deve ter lido mais atentamente e não percebeu.
1º postagem (trecho):
"Padronização NÃO!
Autopakage-likes SIM!"
2º postagem (trecho):
"Padronização NÃO!
Opção de pacote universal SIM!"
3º postagem (trecho):
"Por isso a única solução viável seria ter um sistema de pacotes universal em paralelo aos que já existem, e que não modificasse em nada a estrutura atual das distros."
-----
Nas três postagens a idéia é a mesma, é só ler com mais atenção que se percebe.
-
Vocês estão brigando pelo sentido das palavras, e não pelas coisas em si. É mais ou menos assim: "-- Fulano, você vai para a pescaria?". E Cicrano: "Não, fulano, eu vou pescar!". Estou sentindo no ar uma briga terminológica: quando alguém fala em "padrão" querendo dizer "auto-package likes", outros se arrepiam porque entendem "padrão" como imposição, e no fundo estão falando da mesma coisa.
E também não adianta espernearem, porque coisas como uma "padronização" nos moldes do que as pessoas querem, ou seja, que as distros sejam todas iguais, que se tenha um único sistema de pacotes, um único ambiente de desktop, uma única biblioteca gráfica, etc., isso nunca acontecerá no Linux
Boi, "as pessoas" são os usuários comuns, ou você está falando do pessoal aqui do tópico? Porque se forem as daqui do tópico, aí eu acho que você não entendeu o que eu, komodor, gabriel, etc. defendemos.
-
O Linux não PARECE um caos, É. O caos é uma característica do software livre. É assim que sempre foi e sempre será. As pessoas são livres para desenvolver e usar o que elas querem, portanto não é possível impor padrões. É possível apenas sugerir esses padrões, mas não se pode obrigar ninguém a seguí-los.
Boi, eu não acho que o Linux seja um caos. Se fosse assim, não teríamos softwares como gnome, kde, open office, samba, gimp, que damandam organização por parte dos desenvolvedores e das comunidades para seu desenvolvimento.
Já está mais do que claro de que o padrão de que se fala não será imposto a ninguém, como foi dito no tópico.
-
Vocês estão brigando pelo sentido das palavras, e não pelas coisas em si. É mais ou menos assim: "-- Fulano, você vai para a pescaria?". E Cicrano: "Não, fulano, eu vou pescar!". Estou sentindo no ar uma briga terminológica: quando alguém fala em "padrão" querendo dizer "auto-package likes", outros se arrepiam porque entendem "padrão" como imposição, e no fundo estão falando da mesma coisa.
sim a idéia no fundo do padrão e quem defende autopackage likes é o mesmo mas ai tem um porem,por isso sempre acabei respondendo.
o padrão seria uma espécie de autopackage-like.
mas o autopackage likes no que ele se refere não tem padrão algum. por exemplo
a distribuição debian lança um pacote especie autopackage para ser universal,ou seja nada de padrão,é simplesmente eles que mandam e ninguém mais pode optar. dai a distribuição fedora não vai gostar disso e vai criar um baseado no pacote do debian mas sendo deles,e é obvio que tera diferenças,e assim vai seguinte
ou seja se cria vários pacotes "universais" sendo que nem um realmente irá funcionar fora da distribuição criadora,já sendo um padrão não terá uma distribuição dona e sim todas que aceitarem o padrão poderão mandar lá,sem preferências
-
É exatamente esse o ponto, Komodor, e você tem toda razão. O que eu não tenho certeza é se queriam dizer "mais ou menos como o autopackage, mas sendo padrão de fato" com a expressão "auto-package likes" ou se queriam dizer que o autopackage já seria um padrão, o que não é verdade. Se a primeira hipótese for verdadeira, então eu tenho razão em dizer que a briga é terminológica.
-
Boi, "as pessoas" são os usuários comuns, ou você está falando do pessoal aqui do tópico? Porque se forem as daqui do tópico, aí eu acho que você não entendeu o que eu, komodor, gabriel, etc. defendemos.
Não entendi? Pelo que pude ver, um dos principais argumentos a favor da "padronização" é que isso agradaria aos utilizadores comuns, acostumados a um ambiente onde não existe essa variedade de pacotes e gerenciadores de pacotes que existe no Linux.
-
Meu deus galera, peloamor..tão fazendo tempestade em um copo d'água..
Poxa, ou a é coisa simples demais ou então eu não entendi a seriedade dela :P
Deixa eu ver se é isso:
Primeiro, padronização não é imposição.. no linux seria colocar MAIS UM pacote além dos que já tem(deb,rpm,bin), sendo esse um padrao, ajudaria as empresas privadas que necessitam colocar chave pra ativa produto e tudo mais(inclui aquele joguinhu q vc adora no janelas e q não tem pra linux pq não tem como fazer rodar, pois cada distro tem um "jeito" de "instalar", sem contar q eles precisam colocar numero de série e aquilo tudo.
Então, penso eu, que ao invés de acabar com o linux, q parece q foi assim q receberam a noticia, (não estou falando em ninguem em específico, e nem pensei em nomes, agora, se quer q a carapuça sirva...), isso implementaria ainda mais o nosso querido linux, já que além dos pacotes que já temos, teria um em comum, entre todas as distros.
Bom, se existir esse padrao, nenhuma distro vai ser obrigada a implementar ele(lógico), implementa quem quer, mas isso facilitaria e muito pra usuarios finais (não só os leigos), já que a gama de programas pra linux aumentaria e muito.Dae seria fácil cara, se vc não quer ter no teu pc o padrão.. facil, adquire uma distro q não use e pronto, simples assim..
Então povo.. como eu falei..
Ou a coisa é simples demais ou então eu não entendi a complexidade da coisa ainda..
Bom, espero ter ajudado em algo..
abraços
-
Ozin, a coisa é mesmo simples. Tanto que até já existe um padrão, que é o RPM, definido como padrão pelo LSB. Só que no mundo Linux não é tão fácil assim um padrão "pegar". O LSB é parte de um esforço para criar padrões no Linux, mas é preciso entender que, como você mesmo colocou no seu post, no Linux ninguém pode impor nada. Mas veja que até as pessoas que nesse tópico mais defendem um padrão, rejeitam o RPM. Que contradição!
O que eu acho que acontece, no fundo, é que as pessoas querem mesmo que alguém imponha padrões, mas que imponha mesmo, que obrigue, que force todos a usarem esses padrões, para que elas não tenham a difícil tarefa de fazer escolhas. Como alguém colocou, são pessoas que mudaram para o Linux mas continuam com a cabeça de um usuário Windows.
-
Discordo do post acima, um padrão não vai "pegar" se for imposto. Para um padrão passar a ser adotado amplamente haveria a necessidade de um concenso entre as maiores distrôs em adota-los. Seria algo como já foi apontado em posts anteriores, uma reunião entre as maiores distrôs e um acordo posterior.
Com a disseminação de conteúdo no formato padrão as distrõs médias e pequenas achariam interessante adotar o formato também, e como consequencia o padrão poderia até deixar de ser uma opção secundária e se tornaria a principal a longo prazo.
Penso que o RPM não foi acito amplamente pois já existia o DEB que rivalizava com ele, um terceiro padrão definido em acordo não sofreria com animosidades de grupos com histórico de rivalidade.
-
Certo Nossile, certíssimo Ozin. Boi, não tem nada a ver, cara, ninguém aqui tá falando em impor nada, só você que acha assim. Se eu tivesse a cabeça no windows, eu estaria lá, com toda certeza. A não ser que você ache que utilizar um programa proprietário que só rode no windows, que de repente poderia ser instalado no Linux, é ter a cabeça naquele SO. O que a gente quer é que o acesso aos programas se democratize, que haja uma brecha para que inclusive programas proprietários para windows possam rodar no linux. Todas as distribuições continuariam com seus pacotes originais, sem absolutamente nenhuma diferença. Você continuaria com seu direito de utilizar apenas softwares distribuidos em pacotes próprios, e outros adquiririam o direito de rodar ainda outros programas.
Gostar de softwares que rodam no windows não é gostar do windows (se é esse o problema). Eu estou no linux porque é mais rápido, é bem mais seguro, é mais customizável, etc. Mas eu uso o wine para rodar jogos de windows (além do MSOffice 2003, porque meus irmãos não gostam do BrOffice), e muitos rodam inclusive com um desempenho melhor, o que só reforça a minha paixão por linux. Mas sabemos que nem tudo roda via wine, que muitos desenvolvedores têm dificuldades (ou custos que poderiam ser minimizados) para lançar programas para linux, simplesmente porque as maiores distros ainda não chegaram num acordo para desenvolver um padrão (ou o que se conseguir de mais próximo) de fato. Repito: elas (as distros) não precisariam, e eu nem acharia interessante, abandonar seus pacotes originais, apenas passariam a aceitar mais um.
Agora eu só prometo uma coisa: eu não vou ficar mais ficar me explicando. Já fui claro o suficiente, e a não ser que alguém venha com um argumento de fazer o diabo virar santo, eu não vou mudar de opinião.
-
Não tenho nada contra o Windows, nem contra quem usa esse sistema. Aliás, eu próprio uso Windows. Só que Windows é Windows, Linux é Linux. São sistemas completamente diferentes. E não adianta negarem, essa discussão toda e muitas outras que surgem no fórum existem apenas porque tem gente que quer transformar o Linux num Windows clone, quando isso não é nem possível nem desejável.
Essa desculpa de que as empresas não lançam softwares para Linux por causa dessa falta de padronização dos pacotes é simplesmente uma fantasia. Como já coloquei, para isso existe até uma ferramenta comercial dos mesmos criadores do InstallShield do Windows. Vocês estão procurando chifre em cabeça de cavalo, a explicação para a falta de popularidade do Linux passa longe da falta de padronização dos pacotes.
-
Salve !
E a vida continua....
Abraços
-
Vocês estão procurando chifre em cabeça de cavalo, a explicação para a falta de popularidade do Linux passa longe da falta de padronização dos pacotes.
sabe boi, achu q o lance aqui num é a "popularidade" q está em jogo.. é questão de disponibilidade da gama de softwares q tem, hj temos um monte de software open source, q é uma blza.. mas existem bons softwares proprietarios, q ainda não tem similar no linux q poderia ter a versão pra linux, entendeu?
dae o rpm ser padrao.. ok.. mas me responda.. tem como colocar pra vc inserir código de confirmação pra registrar o produto no rpm? pq pelo q eu sei.. (não sei muito..rs.r.s) não dá..e não é só em rpm não.. é nos deb também..
enfim.. entendeu?
abraços cara..
-
sabe boi, achu q o lance aqui num é a "popularidade" q está em jogo.. é questão de disponibilidade da gama de softwares q tem, hj temos um monte de software open source, q é uma blza.. mas existem bons softwares proprietarios, q ainda não tem similar no linux q poderia ter a versão pra linux, entendeu?
dae o rpm ser padrao.. ok.. mas me responda.. tem como colocar pra vc inserir código de confirmação pra registrar o produto no rpm? pq pelo q eu sei.. (não sei muito..rs.r.s) não dá..e não é só em rpm não.. é nos deb também..
enfim.. entendeu?
abraços cara..
Colocar o serial não seria problema. Mesmo que não for possível, o serial pode ser pedido quando o programa for executado, ao invés de na instalação. No caso de versões trial/shareware, então, nem esse problema existe. E ainda temos que lembrar que ninguém seria obrigado a disponibilzar pacotes RPM, basta que o desenvolvedor use seu próprio instalador, ou que use um instalador comercial, como o InstallShield. Aliás, no Windows funciona assim. Veja que o Opera sempre disponibilizou versões para Linux, mesmo quando era pago, e sempre funcionou.
A razão para a fraca disponibilidade de softwares comerciais para Linux é exatamente a falta de popularidade do sistema. Há muito poucos usuários de Linux em comparação com os usuários de Windows, portanto dificilmente uma empresa vai se voltar para um mercado tão pequeno. Empresas visam lucro, e o lucro está no Windows, que é um mercado gigantesco, e não no Linux, um mercado minúsculo.
-
ae boi, dessa num sabia..
mas assim cara, esse lance de "mercado pequeno" é meio furada não? pq assim cara, eu vejo q cada vez mais o linux vem crescendo.. eu digo isso pelo fato de varios governos, por exemplo o brasil mesmo, adotarem linux como sistema, isso faz com q funcionarios começem a instalar linux em casa, e fica meio q um efeito dominó, pq qndo o cara coloca linux em casa, o filho também aprende, e por ae vai...
digo isso pq eu conheço muuuita gente q ta fazendo isso, geralmente funcionario publico.. sem conta q tenhu amigos q estudam aqui na estadual, q eram realmente contra linux, (na verdade ele tinha até raiva, mas a desculpa era "se está funcionando, pra q mexer?) resultado, mes passado fui lá na casa dele pra instala o linux...Então não acredito q seja o problema de falta de popularidade, pode até ser falta de "popularidade" na cabeça de empresas proprietarias, q não tem conhecimento do linux, ae sim concordo..
mas mesmo assim, acredito q mais um código, sendo esse usado como padrão "melhorariam" as coisas, já q é essa a desculpa q eles dão né? ;)
abraços...
-
mas assim cara, esse lance de "mercado pequeno" é meio furada não?
Infelizmente, não. Apesar do avanço recente do Linux, mercados com grandes populações e níveis elevadíssimos de pirataria como Brasil, China, Rússia e Índia, contribuem fortemente pro domínio do Windows. Nesse contexto o principal apelo do Linux, o fato de ser gratuito, não resulta e ganho de espaço.
Estima-se - com resultados de várias pesquisas feitas por empresas especializadas em TI - que o número de usuários de Linux represente algo em torno de 1% do mercado mundial de SOs:
Windows: 95%
Macs: 3%
Linux: 1%
Outros: 1%
-
mas assim cara, esse lance de "mercado pequeno" é meio furada não?
Infelizmente, não. Apesar do avanço recente do Linux, mercados com grandes populações e níveis elevadíssimos de pirataria como Brasil, China, Rússia e Índia, contribuem fortemente pro domínio do Windows. Nesse contexto o principal apelo do Linux, o fato de ser gratuito, não resulta e ganho de espaço.
Estima-se - com resultados de várias pesquisas feitas por empresas especializadas em TI - que o número de usuários de Linux represente algo em torno de 1% do mercado mundial de SOs:
Windows: 95%
Macs: 3%
Linux: 1%
Outros: 1%
Estranhu cara, queria sabe de q fonte vc pegou essas porcentagens ae?
E assim, se agente considerar o tempo q o windows está como desktop, ou até os mac, o linux ta indo bem.. então assim, ta certo q eu sou um zé ninguem, mas não precisa ser um expert pra perceber esse novo nicho de mercado q está se formando..e dizer q "linux não tem muito usuario" achu q seria meio querer não ver o q está acontecendo.. das 2 uma, ou eles são cego de natureza ou então o tio bill deixa eles cegos com as "verdinhas" na frente deles..rs.rs..
Mas não vamos nos desviar do assunto proposto..
Eu ainda acredito que deveríamos criar um "padrão" além desse RPM ae q o povo num quis adotar..Sabe, os maiores desenvolvedores se juntarem, entrarem em um acordo e decidirem uma nova pra agiliza o serviço.. pq dae a desculpa de q é difícil empacotar pra linux num vai ter mais... e outra.. qnto menos empecilho é melhor, pq já temos q "vencer" a barreira do "novo".. penso q mexer em linux pra muitos, é mais ou menos como foi descobrir as américas, ninguem sabia o q tinha, e foram meio q na "escura", sabe? e temos q mostrar a coisa bonita mesmo, senão o povo corre e num volta mais.. hahahhahaha
abraços ae povo e obrigado ae pelas explicações..
mas sou A FAVOR de se criar um padrão de pacotes para o linux..
-
Windows: 95%
Macs: 3%
Linux: 1%
Outros: 1%
Estranhu cara, queria sabe de q fonte vc pegou essas porcentagens ae?
http://www.w3counter.com/globalstats.php?date=2007-06-10 (http://www.w3counter.com/globalstats.php?date=2007-06-10)
http://marketshare.hitslink.com/report.aspx?qprid=2 (http://marketshare.hitslink.com/report.aspx?qprid=2)
-
mas assim cara, esse lance de "mercado pequeno" é meio furada não?
Estranhu cara, queria sabe de q fonte vc pegou essas porcentagens ae?
Sou usuário há 9 anos de Linux(como desktop, isso, instalado na minha casa), e já digo que teve tempo de sobra pra se consertar n problemas...
O problema é que encabeça o desenvolvimento não tem esse mesmo pensamento. Acha que usuário tem que ficar compilando código, ajustando kernel para seu hardware, entre outros.
O próprio Linus, falou certa vez que um arquivo .doc pra ele é "inlegível". Não duvido que um cara desses edita os textos no LateX e usa o pine pra mandar emails...
Estamos aqui no Ubuntu, graças ao Stallmann... Acho que nem deveria se chamar Linux, e sim, sistema operativo GNU, pois podemos usar outro núcleo (por exemplo, o do solaris, o do freebsd), e ter KDE, Gnome, etc.. rodando.
E Linux necessita de aplicativos que dinamizem o desenvolvimento dos mesmos, como um Visual Studio, um aspX, C Sharp, etc... temos que conviver com qt e gtk é dose.
Carlos
-
O próprio Linus, falou certa vez que um arquivo .doc pra ele é "inlegível". Não duvido que um cara desses edita os textos no LateX e usa o pine pra mandar emails...
Estamos aqui no Ubuntu, graças ao Stallmann... Acho que nem deveria se chamar Linux, e sim, sistema operativo GNU, pois podemos usar outro núcleo (por exemplo, o do solaris, o do freebsd), e ter KDE, Gnome, etc.. rodando.
E Linux necessita de aplicativos que dinamizem o desenvolvimento dos mesmos, como um Visual Studio, um aspX, C Sharp, etc... temos que conviver com qt e gtk é dose.
Eu não sei se o senhor já se preocupou em usar o latex, mas, depois de arrumadas as templates, é só colocar conteúdo. Tudo muito fácil e tranqüilo e se você usa o Kile, até uma criança consegue escrever um documento com as normas da ABNT. A qualidade de um documento feito em latex é impressionante. Nenhum editor WYSIWYG consegue hifenizar e ajustar os caracteres com tamanha precisão (1/10000). Você não precisa se preocupar com espaços duplos, não existe um "modo justificado" (porque o programa já alinha e hifeniza com precisão), fórmulas e tabelas possuem precisão matemática. Enfim, é um outro mundo.
Quanto ao resto, até concordo em parte, mas não consigo visualizar uma pessoa usando um solaris com gnome e kde sem conviver com gtk e qt. Também já ouvi falar muito bem de IDEs como eclipse e glade, mas como não sou programador, não posso dar minha opinião pessoal.
-
Talvez essa notícia anime o pessoal que tá na busca pelo pacote universal, ou pelo menos de um instalador universal de pacotes:
http://www.noticiaslinux.com.br/nl1192577283.html (http://www.noticiaslinux.com.br/nl1192577283.html)
http://blog.ogmaciel.com/?p=364 (http://blog.ogmaciel.com/?p=364)
http://www.packagekit.org/wiki/index.php/Main_Page (http://www.packagekit.org/wiki/index.php/Main_Page)
-
Talvez essa notícia anime o pessoal que tá na busca pelo pacote universal, ou pelo menos de um instalador universal de pacotes:
http://www.noticiaslinux.com.br/nl1192577283.html (http://www.noticiaslinux.com.br/nl1192577283.html)
http://blog.ogmaciel.com/?p=364 (http://blog.ogmaciel.com/?p=364)
http://www.packagekit.org/wiki/index.php/Main_Page (http://www.packagekit.org/wiki/index.php/Main_Page)
Boa notícia essa.
Imagina qdo também tiver essas facilidades nos complicados instaladores tar.gz
-
Vou ser curto e grosso. Manifesto de um programador!
Sou um programador, não quero no momento desenvolver programas para Linux pois não é viável comercialmente. Não posso perder tempo criando arquivos binários para compilação e instalação como .run ou .bin, nem tão pouco estudar durante meses o sistema de empacotamento independente de cada distribuição. Empacotar um produto em .Deb-Debian, Deb-Ubuntu, .RPM-Redhat, RPM-Mandriva, RPM-Suse, TGZ etc...
O motivo é simples. Quero desenvolver o software, o jogo em um único sistema de empacotamento. Prensar os CDs, DVDs, e disponibiliza-los no mercado para que toda a comunidade possa comprar se o produto for atraente, colocar no seu leitor e instalar em qualquer distribuição sem sofrer penalidades de incompatibilidade.
Para desenvolver um software de qualidade ou um jogo complexo levamos muitos meses e até anos e após a conclusão do trabalho, é um absurdo perdemos novamente vários meses empacotando para diversas distribuições tentando alcançar o máximo de usuários possíveis. Também quero preservar meu direito de não liberar o código fonte pois desenvolvo programas de código fechado e não estou disposto a expor o código fonte para a concorrência.
É totalmente inviável produzir um software comercial e variados tipos de empacotamentos. Um jogo de 4GB em Deb, depois em RPM, depois em TGZ. Nesse caso seria necessários várias mídias prensadas e um prejuizo astronômico para a distribuição dos programas pois não alcançaria as massas, teria que criar vários CDs, DVDs personalizados, adaptados para dezenas ou até centenas de distribuições. Um único sistema de empacotamento seria primordial. Seria simples, rápido e viável para todo e qualquer consumidor que deseja adquirir o produto.
Entendam, não posso expor o código fonte para que mantenedores empacotem, assim não estaria tendo retorno financeiro e ainda estaria expondo o código fonte e todo o meu trabalho aos concorrentes. Preciso sustentar meus filhos, minha família e tambem quero me sentir gratificado por anos de estudo e dedicação a programação. Não quero extorquir os consumidores, quero apenas receber pelo meu trabalho.
Esse é o meu pensamento, é tambem o pensamento de milhares de programadores, inclusive as grandes industrias de jogos e softwares exigem até da Microsoft que ela mantenha um padrão de empacotamento para seu sistema, por isso a microsoft mantem o famoso Windows Installer. Isso facilita em muito a vida de qualquer programador na hora de distribuir comercialmente seu produto. Instalação fácil, simples e objetiva, e o melhor, um único sistema de empacotamento, você só precisa estuda-lo uma vez e pronto, pode empacotar todo seu trabalho e distribuir para a massa. Se a comunidade Linux não tomar uma atitude com relação a isso, vai continuar pelejando para convencer grandes insdústrias e pequenos programadores a gastarem milhares de horas desenvolvendo softwares para essa plataforma.
Padronizar é mais do que uma necessidade, é uma obrigação.
Não vejam apenas pelo lado do consumidor, do cliente, mas sim de uma maneira universal, vejam o lado dos programadores que são os ciêntistas que desenvolvem as maravilhas que todos vocês usufruem.
Precisamos de um Sistema de Empacotamento Universal para Linux.
-
Senhor desenvolvedor, isso aqui é software livre, open source. Se o senhor não entende o que é isso, e nem quer entender, como demonstrou em seu post, problema seu. O modelo aqui não é de software fechado, nem nunca será. Se as empresas de software proprietário quiserem produzir para Linux, elas é que terão que se adaptar a um novo modelo de negócios, e não é o Linux que terá que se adaptar a elas. Se não é "viável", paciência.
-
Vou ser curto e grosso. Manifesto de um programador!
Não é apenas um "Manifesto de um programador". É o manifesto de um programador defensor do código fechado e do copyright e também contra as quatro liberdades do software livre.
E pelas idéias que foram expostas eu fico ainda mais convicto de que a pluralidade é a melhor forma de se promover o software livre.
Entendo que todos precisam do "vil metal", mas também entendo que quando pagamos a um desenvolvedor para que ele produza uma ferramenta que nos seja útil, deveríamos estar pagando pelo trabalho que ele teve em produzir uma ferramenta que nos fosse útil. Entretanto, estamos apenas pagando para usar uma ferramenta que pedimos que ele produzisse. Se o programa para um usuário é uma ferramenta, deve ser tratado como tal. O que implica que, uma ferramenta comprada pode ser revendida, repassada, dada (e etc) por quem a comprou pois é o legítimo possuidor. Quando uma ferramenta quebra ou se torna inadequada, temos sempre alguém a quem recorrer: seja o serviço autorizado (normalmente também o fabricante) ou um técnico com conhecimento adequado para o trabalho e em ambos os casos é devido o pagamento por todo o trabalho que for necessário para o conserto ou aprimoramento da ferramenta (e deve ser bem remunerado). Sem mencionar nos serviços de manutenção, atualização, etc, todos esses são onerosos e merecem uma contraprestação.
Salvo na Arte, onde músicos, escritores, cantores, instrumentistas vivem de shows e direitos autorais, todos os demais trabalhadores ganham pelo trabalho que executam, à medida que o fazem. O desenvolvedor de software é um artista ou é um trabalhador como os demais?
A contraprestação no mundo do software livre pode vir de várias formas: documentação; beta-testers; forum; divisão de trabalho; suporte; pagamento por instalação, configuração, suporte e treinamento; feedback de críticas e sugestões; pagamento pelas mídias do programa e dos manuais, etc.
E, ao contrário do que se pensa, não é porque existem várias distros que se tem que fazer um pacote pre-compilado para cada uma delas. A grande maioria dos pacotes que não dependem de outros pacotes típicos da distro funcionam muito bem em qualquer sistemae só vai precisar em um RPM, um DEB e um TGZ para jogar os arquivos em /opt/programa com links simbólicos em /bin para os executáveis.
-
Senhor desenvolvedor, isso aqui é software livre, open source. Se o senhor não entende o que é isso, e nem quer entender, como demonstrou em seu post, problema seu. O modelo aqui não é de software fechado, nem nunca será. Se as empresas de software proprietário quiserem produzir para Linux, elas é que terão que se adaptar a um novo modelo de negócios, e não é o Linux que terá que se adaptar a elas. Se não é "viável", paciência.
É justamente esse tipo de pensamento que faz com que o linux não cresca como deveria. Software livre nem sempre quer dizer software free. É muito grande o apelo de usuários do sistema Linux com relação a disponibilidade de vários programas e principalmente jogos. Existe um desejo muito grande da comunidade que as industrias portem seus jogos para o Linux e muitos usuários estão dispostos a pagar por eles. Hoje no mercado existem uma quantidade enorme de programas e jogos que poderiam ser portados para o Linux, mas a falta de uma padronização impede que eles sejam portados pois dificultam o trabalho da equipe de desenvolvimento do software. Não estou aqui criticando a filosofia do software free. Até por que a maioria dos programadores tambem contribuem para o desenvolvimento desses softwares e vivem de doações de industrias e empresas de grande porte. Estou defendendo a padronização e unicamente isso. Se o programador quer liberar seu código fonte ou não é uma questão pessoal ou muitas vezes está atrelado a um contrato com uma determinada industria de software.
Um software de grande porte demanda muito tempo e dinheiro, desenvolver durante anos um jogo ou aplicativo de animação exige uma grande equipe e muito dinheiro para manutenção do projeto. É natural que empresas queiram receber pelo trabalho desenvolvido. Se eu sou um programador financiado por uma empresa, ela determina qual será o termo de licença do produto e por que não liberar sobre uma licença livre e free. Isso pode ser feito, mas para tal é necessário que a mesma possa se manter através de alguma base de sustentação financeira.
Eu sou simpatizante do sofware livre e tambem do software free e torço sinceramente para o sucesso do sistema Linux. No entando é preciso ter uma posição mais moderada e uma visão que beneficie várias camadas da sociedade. Me cadastrei nesse forum para apoiar a padronização para o bem dos programadores, desenvolvedores e principalmente dos usuários.
Quem quer produzir software sobre licença free, livre, shareware, adware, proprietária que produza. Os bons produtos sempre irão sobreviver pois encontraram seu nicho de consumo. Não estou fazendo uma defesa de um ou outro tipo de licença e sim a padronização de empacotamento para facilitar a vida dos desenvolvedores e consequentemente trazer o benefício aos usuários pois antes de ser um desenvolvedor sou um usuário multi-plataforma e tambem consumo produtos que possuem váriados termos de licença. Ao meu ver não existe software gratuito, existe software doado pois todo desenvolvimento, seja de uma calculadora até um banco de dados ou o que mais puder imaginar demanda tempo e dinheiro. Talvez somente quem é desenvolvedor saiba com plena clareza o significado dessa afirmação.
Boa sorte a todos e principalmente ao autor do tópico aberto, espero que alcance o sucesso esperado.
-
O mais incrível disso tudo é saber que existem pessoas que produzem seus softwares e os disponibilizam gratuitamente, ninguém sabe o porquê, só sabemos que o fazem.
Eu estou estudando na área de computação, e certamente farei programas proprietários, mas também contribuirei com projetos de comunidades, ou seja, doarei meu tempo e conhecimento para o benefício de outros, isso porque eu tenho sido também beneficiado, é assim e será do mesmo jeito por muito tempo.
Vale lembrar de uma frase: O que de graça recebe, também de graça deve doar.
Não defendo que tudo seja open source, mas digo que não deve haver radicalismo, nem por copyleft nem por copyright.
Mas devo concordar que é necessário padronização no Linux, não de maneira forçada, mas como um modelo a ser seguido, ou seja, segue quem quer, quem não quer fica no seu.
-
Software livre nem sempre quer dizer software free.
Sem comentários.
-
povo, realmente.. software livre não quer dizer software gratis, e qm discorda, da uma estudadinha sobre software livre q vai ver.. o detalhe é o seguinte.. eu entendo q vcs programadores fiquem preocupados com a "concorrencia", mas convenhamos.. vc trocaria uma assistencia técnica autorizada por uma "diabo", se a assistencia tecnica autorizada não fosse abusiva e funcionasse?
defender o copright é como dizer q é correto vc comprar um carro, e ter o capô lacrado.. onde só o criador pode mexer.. se o teu criador não der mais satisfação pra vc (vcs q são bons programadores e bons técnicos sabem q isso existe de monte) vc fica a ver navios... teria q jogar o carro inteiro fora e comprar de outro fabricante, pois não teria como mandar outra pessoa fazer... O problema disso tudo é q os incompetentes (fiquem calmos, não estou falando diretamente pra nenhum de vcs, q tenhu ctz q são bons programadores ;)), com o software livre não terão mais vez, pois se eu contrato o serviço de um concorrente de vcs, e ele começar a ser abusivo no preço, não der mais assistencia pro meu software, ou então não der mais atenção pra mim, eu pegarei o programa q eu mesmo comprei (pagando para q o desenvolvedor faça esse software e pagando as mensalidades como acontece com o copright) e levarei pra alguma pessoa q seja competente fazer o serviço..( e q começará a ganhar meu suado dinheirinho da mensalidade para me dar manutenção nesse software).
Então assim, eu acredito SIM, q precisa ter um instalador universal (entre as distros linux) ou um pacote padrão, para que se a pessoa q quer vender o software dele com o codigo fechado ou aberto(respeitando sempre a liberdade de escolha), o faça tranquilamente, sem se preocupar em compilar para trocentas distros. E vamos cuidar com um lance ae pessoal.. liberdade de escolha sim, agora, imposição de liberdade NÃO. :)
abraços a todos ;D
-
apoiado!
-
apoiado!
To dentro!!
-
apoiado!
To dentro!!
Você apoiam um padrão de pacotes para o Linux?
Pessoal eu recomendo que vocês leiam o tópico inteiro.
Um padrão de pacotes é completamente inviável e traria muito mais problemas que benefícios ao Linux.
Lembrando que Linux não é Windows, são modelos completamente diferentes. Se no Linux temos a liberdade e diversidade que temos hoje, é justamente porque ele não os modelos de desenvolvimento do Windows
-
Prós e Contras do padrão de pacotes
vou tentar fazer uma comparação dos prós e dos contras de haver um padrão de pacotes no linux
PRÓS
Um pacote padrão ajudaria os desenvolvedores independentes, que não tem condições de testar os programas em várias distros
Tornaria mais fácil a atualização de programas, uma vez que não seria necessário esperar pelos repositórios oficiais
Desafogaria os servidores das distribuições, já que os pacotes se encontrariam nos repositórios dos desenvolvedores ( ex.: pacote do firefox seria baixado do servidor da mozilla pelo apt )
Um programa desenvolvido para uma distro poderia ser instalada em outra sem maiores problemas
CONTRAS
Acabaria com a liberdade de escolher entre um tipo de pacote e outro
Distros teriam que se adaptar ao novo tipo de empacotamento
Haveria rejeição por parte das comunidades
se alguém achar que pode acrescentar algo, por favor fique a vontade
-
Aos que gostariam de um tipo padrão de empacotamento fica a pergunta:
Quem vai determinar o tipo de pacote? Quem vai determinar as regras/normas do empacotamento? Quem vai ficar responsável para controlar se o pacote esta sendo empacotado de forma correto (validar cada pacote)? Quem vai gerir tudo?
Pergunto isto porque, tomando o exemplo do Debian, não basta você empacotar algo (mesmo um software que todos querem e ainda não esteja nos repositórios) para ele será adicionado aos repositórios. Existe todo um processo de validação do pacote até que ele possa ser incluído nos repositórios, e isto realmente não é simples.
E ai ainda tem mais, mesmo que só existisse um tipo de empacotamento eu provavelmente não usaria (ou pensaria bem antes de usar) nenhum pacote fora dos repositórios, isto simplesmente porque eles provavelmente não são testados/conferidos nos mínimos detalhes, e acreditem um pacote mal construído pode fazer mais mal do que bem ao seu sistema, mesmo que só existisse um tipo dele.
[]'s
Cristiano
-
vou tentar fazer uma comparação dos prós e dos contras de haver um padrão de pacotes no linux
PRÓS
Um pacote padrão ajudaria os desenvolvedores independentes, que não tem condições de testar os programas em várias distros
Tornaria mais fácil a atualização de programas, uma vez que não seria necessário esperar pelos repositórios oficiais
Desafogaria os servidores das distribuições, já que os pacotes se encontrariam nos repositórios dos desenvolvedores ( ex.: pacote do firefox seria baixado do servidor da mozilla pelo apt )
Um programa desenvolvido para uma distro poderia ser instalada em outra sem maiores problemas
Isso não tem o menor sentido. Desenvolvedores independentes já têm uma forma de ter pouco trabalho, que é justamente disponibilizar o código fonte, deixando para as distros, ou mesmo para terceiros, a responsabilidade de empacotar o software.
De resto, já foi colocado que seria muito difícil fazer pacotes que funcionassem sem problemas de compatibilidade em qualquer distro, mesmo que houvesse apenas um sistema de pacotes. O ideal é disponibilizar o código fonte, que normalmente pode ser compilado não só em qualquer distro, mas geralmente também em outros sistemas, como os BSDs, o Solaris, o MacOSX, e às vezes até no Windows. Para quem reclama que não existe um pacote universal, ele existe, é o tar.gz.
Agora, se a preocupação for desenvolvedores de código fechado, bom, aí o problema é deles. A Opera é uma empresa de código fechado que conseguiu resolver bem esse problema, e não é exatamente um gigante do software. Se ela consegue, outros também conseguem, se quiserem. O problema é que não querem, não têm o mínimo interesse em Linux, então não há porquê se preocupar com eles.
-
Vocês estão sendo redundantes. Já foi exaustivamente repetido e refrisado no tópico que um padrão não anularia o sistema de pacotes nativo de cada distro, e que o padrão nasceria num esforço conjunto das principais distros. Igualmente, ninguém nega a dificuldade de implementação de mais um sistema de pacotes, que deve funcionar paralelamente ao default da distro.
De qualquer forma, volto a repetir que um esforço nesse sentido é importante, pois isso facilitaria a portabilidade de uma série de softwares proprietários para linux. Entendam bem: não se trata de tornar o linux igual ao windows (que é o que muita gente pensa), mas apenas de dar àqueles que precisam de softwares proprietários o direito de utilizá-los num sistema linux.
-
Prós e Contras do padrão de pacotes
vou tentar fazer uma comparação dos prós e dos contras de haver um padrão de pacotes no linux
PRÓS
Um pacote padrão ajudaria os desenvolvedores independentes, que não tem condições de testar os programas em várias distros
Tornaria mais fácil a atualização de programas, uma vez que não seria necessário esperar pelos repositórios oficiais
Desafogaria os servidores das distribuições, já que os pacotes se encontrariam nos repositórios dos desenvolvedores ( ex.: pacote do firefox seria baixado do servidor da mozilla pelo apt )
Um programa desenvolvido para uma distro poderia ser instalada em outra sem maiores problemas
CONTRAS
Acabaria com a liberdade de escolher entre um tipo de pacote e outro
Distros teriam que se adaptar ao novo tipo de empacotamento
Haveria rejeição por parte das comunidades
se alguém achar que pode acrescentar algo, por favor fique a vontade
é, por um lado, uma das coisas que mais diferencia as distros são seus pacotes, no entanto, a idéia de se padronizar os pacotes, mas não as distros não é ruim, realmente existem prós só que os contras são um pouco maiores.. :-\
-
Você já conhecem o packagekit, vejam no blog do og maciel http://blog.ogmaciel.com/?p=364. Vejam o site dele para conhecerem melhor http://www.packagekit.org/
-
Vocês estão sendo redundantes. Já foi exaustivamente repetido e refrisado no tópico que um padrão não anularia o sistema de pacotes nativo de cada distro, e que o padrão nasceria num esforço conjunto das principais distros. Igualmente, ninguém nega a dificuldade de implementação de mais um sistema de pacotes, que deve funcionar paralelamente ao default da distro.
De qualquer forma, volto a repetir que um esforço nesse sentido é importante, pois isso facilitaria a portabilidade de uma série de softwares proprietários para linux. Entendam bem: não se trata de tornar o linux igual ao windows (que é o que muita gente pensa), mas apenas de dar àqueles que precisam de softwares proprietários o direito de utilizá-los num sistema linux.
Vocês é que não querem entender que a falta de pacote padronizado não é problema. Falta de softwares proprietários no Linux? E daí? Software proprietário não combina com Linux. Mas se mesmo assim as empresas quiserem lançar seus softwares para Linux, tudo bem, mas elas é que têm que se adaptar ao Linux, e não o contrário. Como já disse, quem teve interesse se adaptou, como a Opera.
Isso me lembra daquele grupo que se ofereceu para desenvolver drivers de graça para as empresas de hardware, aceitando todas as condições, inclusive os termos de confidencialidade. Eles estão sem ter o que fazer, pois pouquíssimas empresas se interessaram, mesmo eles fazendo todas as concessões possíveis. O troll mor do Meio Bit escreveu um artigo elogiando essa iniciativa, queria ver o que ele diria agora que o projeto está sendo um fracasso.
Com essa história do pacote padronizado é o mesmo. A única vantagem seria facilitar a vida dos produtores de software proprietário, mas esses não dão a mínima bola para o Linux, e nem darão, mesmo porque é um mercado muito pequeno. Então, para que perder tempo com isso?
-
Vocês estão sendo redundantes. Já foi exaustivamente repetido e refrisado no tópico que um padrão não anularia o sistema de pacotes nativo de cada distro, e que o padrão nasceria num esforço conjunto das principais distros. Igualmente, ninguém nega a dificuldade de implementação de mais um sistema de pacotes, que deve funcionar paralelamente ao default da distro.
De qualquer forma, volto a repetir que um esforço nesse sentido é importante, pois isso facilitaria a portabilidade de uma série de softwares proprietários para linux. Entendam bem: não se trata de tornar o linux igual ao windows (que é o que muita gente pensa), mas apenas de dar àqueles que precisam de softwares proprietários o direito de utilizá-los num sistema linux.
Vocês é que não querem entender que a falta de pacote padronizado não é problema. Falta de softwares proprietários no Linux? E daí? Software proprietário não combina com Linux. Mas se mesmo assim as empresas quiserem lançar seus softwares para Linux, tudo bem, mas elas é que têm que se adaptar ao Linux, e não o contrário. Como já disse, quem teve interesse se adaptou, como a Opera.
Isso me lembra daquele grupo que se ofereceu para desenvolver drivers de graça para as empresas de hardware, aceitando todas as condições, inclusive os termos de confidencialidade. Eles estão sem ter o que fazer, pois pouquíssimas empresas se interessaram, mesmo eles fazendo todas as concessões possíveis. O troll mor do Meio Bit escreveu um artigo elogiando essa iniciativa, queria ver o que ele diria agora que o projeto está sendo um fracasso.
Com essa história do pacote padronizado é o mesmo. A única vantagem seria facilitar a vida dos produtores de software proprietário, mas esses não dão a mínima bola para o Linux, e nem darão, mesmo porque é um mercado muito pequeno. Então, para que perder tempo com isso?
Uma das coisas que mais gosto no Linux é a liberdade.
Antes de continuar me digam uma coisa... Quem consegue defender que este padrão vai funcionar em paralelo com o empacotamento atual da distro, já que seria criado após "um esforço conjunto das principais distros" e que "ninguém nega a dificuldade de implementação de mais um sistema de pacotes"??
Pelo amor de Deus, se da trabalho, e não é fácil fazer, é lógico que o empacotamento atual seria deixado de lado, e ai perderiamos a liberdade.
Voltando, trabalho com Linux a um bom tempo, e acho que são poucos os que já vem lutando a algum tempo que desejam abrir mão de sua liberdade. Vir para o Linux é passar a aceitar o que tem aqui, com seus prós e contras. E uma coisa sensata é que se o Opera pode fazer empacotamento para as distros porque os outros não podem?
As empresas (de jogos, por exemplo) não criam programas para o Linux simplesmente porque o percentual dele é baixo no mercado, Aposto que se fosse de 50% ela faria pacotes para n distros sem chorar.
Bem, como aqui é para colocar opinião esta é a minha, respeito a de vocês, mesmo achando que ela não é a ideal, mas como estamos no linux é isto, liberdade para escolha do empacotamento, liberdade para escolha da interface, e liberdade de pensamentos... viva a liberdade, ao menos por enquanto!
[]'s
Cristiano
-
-As empresas que se interessam pelo mercado Linux e não querem empacotar para várias distros, distribuem seus aplicativos em ".run" ou ".bin".
-Quando o Linux tiver uma parcela de mercado finaceiramente interessante, as empresas que antes o ignoravam irão distribuir seus produtos pra Linux de qualquer maneira: seja com vários pacotes para várias distros, seja com .bin ou .run.
Em resumo:
Um padrão de pacotes não é necessário.
E o Linux não vai ganhar mais adeptos por causa disso.
-
Sei lá pessoal, sem querer ofender mas esse tópico já ficou chato. Os dois grupos estão repetindo os mesmos argumentos desde o inicio do tópico, não levando os argumentos do outro grupo em consideração e sendo taxativos.
O GNU/Linux está em processo de evolução contínua, se em um futuro próximo ficar evidente que um opção universal (rápida e simples) de empacotamento ajudará ele a se expandir mais ou mais rápido essa implementação vai ser adotada. Isso se dará da mesma forma que aconteceu com o visual e usabilidade das distribuições, que mudaram demais em (relativo) pouco tempo, mesmo com pessoas que pensavam que isso era besteira.
-
Sei lá pessoal, sem querer ofender mas esse tópico já ficou chato. Os dois grupos estão repetindo os mesmos argumentos desde o inicio do tópico, não levando os argumentos do outro grupo em consideração e sendo taxativos.
O GNU/Linux está em processo de evolução contínua, se em um futuro próximo ficar evidente que um opção universal (rápida e simples) de empacotamento ajudará ele a se expandir mais ou mais rápido essa implementação vai ser adotada. Isso se dará da mesma forma que aconteceu com o visual e usabilidade das distribuições, que mudaram demais em (relativo) pouco tempo, mesmo com pessoas que pensavam que isso era besteira.
É mesmo, esse tópico já deu o que tinha que dar.
Ele não sai do canto há algum tempo. ;D
-
O GNU/Linux está em processo de evolução contínua, se em um futuro próximo ficar evidente que um opção universal (rápida e simples) de empacotamento ajudará ele a se expandir mais ou mais rápido essa implementação vai ser adotada.
Não, não vai. O que você e muita gente não quer entender é que Linux é uma coisa e Windows e demais sistemas comerciais são outras completamente diferentes. O Linux não está aí para dominar o mundo. Pouco importa se esse sistema de pacotes unificado ajudaria ou não o sistema a se tornar popular. Isso não é e nunca será adotado, queiram vocês ou não. E por um motivo muito simples: no Linux ninguém tem poder de impor padrões. Não adianta virem com essa historinha de que um só sistema de pacotes, um só ambiente gráfico, e a última que arrumaram, uma só distro, facilitaria a adoção do Linux pelas massas, porque isso tudo simplesmente é impossível de acontecer. Queiram ou não, é assim que funciona, qualquer um pode fazer sua própria distro, seu próprio ambiente gráfico, seu próprio sistema de pacotes, e se for bom, muita gente vai usar. Se essa diversidade, se essa liberdade toda atrapalha, paciência. O Linux, como já disse, não está aí para dominar o mundo, está aí para ser uma alternativa, apenas isso.
-
Não, não vai. ...
Isso é sua opinão, uma opinião e só, não tem como ser taxativo a esse ponto e afirmar que algo vai ou não acontecer. ::)
-
Continuar a discutir isso não vai levar a lugar algum. Eu postei a camparação de prós e contras para que quem estivesse em dúvida pudesse ter uma base para se decidir.
Convém agora respeitar a opinião alheia e, com todo respeito, não postar opiniões em fontes destacadas.
Estamos no linux e temos liberdade para escolher se queremos utilizar um pacote padrão ou não, cabe a cada um decidir o melhor para si mesmo e respeitar a escolha do outro.
O Linux está mostrando que pode ser economicamente rentável, basta verem o Mandriva, SUSE, RedHat, e até mesmo o Ubuntu, no qual podemos comprar o suporte.
Eu vejo que no futuro, se não houver a adoção do pacote padrão, vai haver um pacote que será padrão de fato (só pra citar o exemplo do formato .doc, que não é padrão da ISO), que provavelmente virá da distro que conseguir se lançar melhor no mercado, já que linux não é mais para estudantes de computação e empresas apenas, é também para "seres humanos".
Observemos pois as diferenças, respeitemos, e escolhamos, pois, o que a nós nos parecer melhor.
-
Convém agora respeitar a opinião alheia e, com todo respeito, não postar opiniões em fontes destacadas.
Tem razão sobre as fontes em destaque, me excedi um pouquinho.
Vou editar lá o post.
E essa discussão realmente já encheu o saco.
-
Que a discussão é inútil, isso concordo. Só mais um tópico de gente que quer transformar o Linux num Windows clone, já tiveram centenas de tópicos como esse aqui no fórum. Mas podem espernear à vontade, o Linux não vai se transformar num clone do Windows, não tem como.
-
Salve!
Déjà vu :
E a vida continua....
Abraços
-
Não entendi o que tem haver a possibilidade de existencia de um pacote comum opcional para as principais distribuições com o Linux se tornar "clone do Windows". ::)
...mas deixa pra lá.
-
Que a discussão é inútil, isso concordo. Só mais um tópico de gente que quer transformar o Linux num Windows clone, já tiveram centenas de tópicos como esse aqui no fórum. Mas podem espernear à vontade, o Linux não vai se transformar num clone do Windows, não tem como.
Eu acho que padronização não quer dizer transformar o linux num clone do windows, para tanto precisaríamos das telas azuis ;D
Humor a parte, a criação desse tópico foi um esforço para tentar melhorar a vida de muita gente, mas como eu disse antes, cabe a cada um decidir o melhor para si mesmo e repeitar a opinião dos outros.
E tenho dito!
-
O problema de ressuscitar um tópico antigo é um só: muitos novos comentários ignorando toda a discussão prévia. A sensação que fica é que todo o debate foi inútil. E o que foi dito sobre LSB? E o que foi dito sobre como funciona um empacotamento? Será que tem que ficar copiando e colando das páginas anteriores ou está de fato perdido?
Só pra pensarem um pouquinho, por que vocês acham que existem estes diretórios?
/bin
/usr/bin
/usr/local/bin
e?
/sbin
/usr/sbin
/usr/local/sbin
Sem falar nos que criam seus próprios diretórios fora do padrão:
/opt/grisoft/avg7/bin
/opt/grisoft/avggui/bin
/usr/java/jre1.6.0_02/bin
/usr/kerberos/bin
/usr/kerberos/sbin
/usr/lib/avast4workstation/bin
/usr/lib/vmware/bin
/usr/local/Adobe/Acrobat7.0/bin
/usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin
É até difícil escrever qualquer comentário sobre pacotes que já não foi dito antes.
-
por um lado percebo o ponto de vista do Boi, por ser a 'biodiversidade' dos formatos, distribuições, etc., que faz o Linux ter a qualidade que tem.
Por outro lado concentrar os esforços numa norma não é má ideia - por exemplo cá em Portugal temos uma distribuição chamada Caixa Mágica, que tem alguma preocupação no suporte localizado, como provedores de internet, os modems fornecidos pelos provedores (aquelas famosas porcarias usb), etc., mas é baseada em pacotes rpm - e a distribuição de linux mais popular cá também é Ubuntu, e lá está, .deb ... - se o formato de pacotes fosse unico, távamos todos a utilizar na boa o suporte da Caixa Mágica, e esta distribuição estaria a crescer sinergicamente muito mais do que agora, e se calhar até poderia estar a existir alguma parceria, que seria muito saudável.
E se não me engano, o Ubuntu não surgiu uns anos depois da iniciativa United Linux, que foi um esforço em simplicar e unificar aquilo que mais divergia entre as distribuições? E o open-desktop (se não me engano no nome também) não foi uma tentativa também em tentar compatibilizar a diversidade de gestores de janelas, principalmente por causa da 'telenovela' Gnome-vs-KDE?