LWN: "Debian propõe cessar suporte à maioria das arquiteturas"
O LWN reproduziu a íntegra da mensagem de Steve Langasek (que ocupa o cargo de 'Release manager' no projeto Debian) relatando as conclusões de um recente evento reunindo parte dos responsáveis por esta popular distribuição. Entre diversos assuntos mencionados, o que mais atraiu a atenção foi a proposta de uma redução nas arquiteturas suportadas pelo projeto, que passaria a suportar apenas x86, AMD64, PowerPC e IA-64 (cortando, entre outros, Sparc, PA RISC, MIPS, ARM e S/390). Segundo Langasek, isto vai reduzir drasticamente as necessidades de coordenação entre arquiteturas, e possivelmente reduzir o ciclo de lançamentos para uma ordem de 12 a 18 meses. As arquiteturas cortadas pela proposta poderão ser mantidas de alguma outra forma, mas se a proposta for aceita (o que não deverá ocorrer sem grandes modificações, a julgar pelo volume das discussões) deixarão de fazer parte do processo de desenvolvimento oficial do Debian. Mais no The Register.
(postado por Augusto Campos)
Comentários dos leitores
Comentário de thinkwink
15/03/05 16:54
Precisa mais: Acho que além de reduzir as arquiteturas também é preciso reduzir drasticamente o número de pacotes, 70% dos pacotes do debian são simplesmente desnecessários e quase ninguem os usa, deixando só o processo de release mais demorado por causa de alguns desses pacotes.
Comentário de Manoel Pinho
15/03/05 17:07 - usuário registrado #8
Re: precisa mais: Concordo. A distribuição deveria manter um núcleo principal com uma rigorosidade habitual de aceitação e os outros pacotes ficariam num repositório "contrib" ou "extras", como outras distribuições fazem.
Não gosto de ciclos muito curtos (menos de 6 meses) entre lançamentos de novas versões, mas também mais de um ano fica difícil usar também. Se colocassem um prazo de tempo mais ou menos rígido, tipo 1 ano, seria legal para os usuários poderem planejar as migrações. A Ubuntu está fazendo isso (só que são 6 meses se não me engano).
Outra coisa legal seria poder instalar rpms de uma forma mais fácil e integrada com a distribuição. Queiram ou não, o rpm já virou um padrão de fato e adotado pelo LSB, e cada vez vemos mais softwares proprietários sendo empacotados em rpm. Não creio que seja impossível gerenciar pacotes deb e rpm simultaneamente, ou talvez até propor um formato novo que integrasse os dois de maneira não drástica.
Não gosto de ciclos muito curtos (menos de 6 meses) entre lançamentos de novas versões, mas também mais de um ano fica difícil usar também. Se colocassem um prazo de tempo mais ou menos rígido, tipo 1 ano, seria legal para os usuários poderem planejar as migrações. A Ubuntu está fazendo isso (só que são 6 meses se não me engano).
Outra coisa legal seria poder instalar rpms de uma forma mais fácil e integrada com a distribuição. Queiram ou não, o rpm já virou um padrão de fato e adotado pelo LSB, e cada vez vemos mais softwares proprietários sendo empacotados em rpm. Não creio que seja impossível gerenciar pacotes deb e rpm simultaneamente, ou talvez até propor um formato novo que integrasse os dois de maneira não drástica.
Comentário de hamacker
15/03/05 17:19 - usuário registrado #168
Concordo, .rpm pode não ser: Concordo, .rpm pode não ser o melhor formato que existe, porém foi o padrão que foi adotado no LSB. Ou se adota o RPM de vez (o que acho dificil, pois ninguem vai disperdiçar a base que já existe), ou faz uma solucao que permita os dois formatos conviverem harmoniosamente.
O slackware já fiz isso a bastante tempo.
O slackware já fiz isso a bastante tempo.
Comentário de André Luís Lopes
15/03/05 20:02
Perdoe-me se estiver errado,: Perdoe-me se estiver errado, mas, ao que aparece, o que foi adotado pelo LSB foi um subconjunto do RPM. Para que distribuições sejam consideradas compatíveis com o padrão LSB *nesse quesito*, seria necessário que as mesmas fossem capazes de instalar tais pacotes.
Porém, o Debian já fornece o próprio gerenciador de pacotes RPM (pacote Debian de nome "rpm") há muito tempo. Ou seja, quanto a isto, não haveria problema, os pacotes LSB poderiam ser instalados, apesar da LSB ser muito mais que simplesmente um formato específico de pacotes (não estou dizendo que você disse que é, só estou comentando).
De qualquer forma, utilizar o gerenciador de pacotes "rpm" em um sistema Debian não é lá muito inteligente, uma vez que os pacotes instalados com o auxílio desse utilitário iriam "bypassar" o sistema de pacotes Debian.
Na verdade, não sei como ficaria isso na realidade, visto que nunca instalei um pacote RPM em Debian. Nunca precisei.
Porém, o Debian já fornece o próprio gerenciador de pacotes RPM (pacote Debian de nome "rpm") há muito tempo. Ou seja, quanto a isto, não haveria problema, os pacotes LSB poderiam ser instalados, apesar da LSB ser muito mais que simplesmente um formato específico de pacotes (não estou dizendo que você disse que é, só estou comentando).
De qualquer forma, utilizar o gerenciador de pacotes "rpm" em um sistema Debian não é lá muito inteligente, uma vez que os pacotes instalados com o auxílio desse utilitário iriam "bypassar" o sistema de pacotes Debian.
Na verdade, não sei como ficaria isso na realidade, visto que nunca instalei um pacote RPM em Debian. Nunca precisei.
Comentário de André Luís Lopes
15/03/05 20:05
É uma *proposta*, não uma d: É uma *proposta*, não uma decisão tomada. Na verdade, esta questão está em intensa discussão na lista debian-devel. Existe uma thread com mais de 400 mensagens e a mesma continua crescendo neste exato momento que escrevo.
Minha caixa-postal está realmente lotada de mensagens hoje :-)
Minha caixa-postal está realmente lotada de mensagens hoje :-)
Comentário de Cesar Cardoso
15/03/05 20:07
Faz todo o sentido...: Não há nenhuma perspectiva de data de lançamento da Sarge, a lista de backports em http://www.backports.org está cada dia maior, cada vez mais recorrer às ciências ocultas é necessário para instalar o Woody em hardware relativamente moderno...
É uma medida extrema? Certamente é. Mas dizer que "a partir de agora só 4 arquiteturas terão releases e o resto que vá se ver com a sid" é duro, mas para um projeto com recursos limitados faz sentido. Claro que corre-se o risco de virar um NetBSD, que é portado para quase todas as plataformas possíveis e imaginárias, mas que pelo menos uns 60% delas ninguém atualiza.
Ou isso ou ninguém mais iria se importar com a Debian, mas sim com Ubuntu, Knoppix, Debian-BR-CDD, Kurumin etc etc etc
É uma medida extrema? Certamente é. Mas dizer que "a partir de agora só 4 arquiteturas terão releases e o resto que vá se ver com a sid" é duro, mas para um projeto com recursos limitados faz sentido. Claro que corre-se o risco de virar um NetBSD, que é portado para quase todas as plataformas possíveis e imaginárias, mas que pelo menos uns 60% delas ninguém atualiza.
Ou isso ou ninguém mais iria se importar com a Debian, mas sim com Ubuntu, Knoppix, Debian-BR-CDD, Kurumin etc etc etc
Comentário de Patola
15/03/05 20:26 - usuário registrado #184
Tiro no pé: Acho que seria um tiro no pé, pois uma das *maiores* vantagens do debian é a quantidade e qualidade de pacotes oficiais. Fazer 'downsizing' iria simplesmente piorar a distribuição.
--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!
--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!
Comentário de Patola
15/03/05 20:36 - usuário registrado #184
Metadistribuição: Se o Debian deixar de apresentar características que o deixem bom como uma 'metadistribuição', isso será daninho para as que são derivadas dele como Kurumin, Knoppix, Ubuntu, Linspire, etc. Pra que mudar o que funciona?
Lembrando que o Debian NÃO É SÓ a árvore stable, embora todo mundo só esteja falando dela. E ter pacotes estáveis super-mega-testados na árvore stable (ainda que antigos) não é necessariamente uma desvantagem na óptica de todo mundo. Os maníacos por segurança podem fazer questão disso, por exemplo.
Quanto a mudar pra RPM pra satisfazer a LSB, não vai acontecer. Ser .deb é uma das coisas que identificam a distribuição e sua identidade certamente se alicerça nisso. Debian mudar pra RPM seria o equivalente a todos os desenvolvedores unanimamente desistirem das diretivas, procedimentos e decisões de projeto da distribuição. O máximo que pode haver é alguma integração externa, como um "alien" mais forte. Mudar pra rpm não é só uma decisão de tipo de pacotes, envolve muito mais coisa, como configuradores do sistema, inicialização, integração dos aplicativos e daí por diante. Quem aí já viu a assustadora quantidade de utilitários dpkg-algumacoisa ou apt-outracoisa que existem na distribuição?
Por último: distribuições erigidas em cima do Debian como Ubuntu, Knoppix e Linspire funcionam. Pra que mudar isso? Se você não quer usar um dos três debians (stable, testing ou unstable), use essas distribuições. Vai continuar podendo usar os pacotes...
--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!
Lembrando que o Debian NÃO É SÓ a árvore stable, embora todo mundo só esteja falando dela. E ter pacotes estáveis super-mega-testados na árvore stable (ainda que antigos) não é necessariamente uma desvantagem na óptica de todo mundo. Os maníacos por segurança podem fazer questão disso, por exemplo.
Quanto a mudar pra RPM pra satisfazer a LSB, não vai acontecer. Ser .deb é uma das coisas que identificam a distribuição e sua identidade certamente se alicerça nisso. Debian mudar pra RPM seria o equivalente a todos os desenvolvedores unanimamente desistirem das diretivas, procedimentos e decisões de projeto da distribuição. O máximo que pode haver é alguma integração externa, como um "alien" mais forte. Mudar pra rpm não é só uma decisão de tipo de pacotes, envolve muito mais coisa, como configuradores do sistema, inicialização, integração dos aplicativos e daí por diante. Quem aí já viu a assustadora quantidade de utilitários dpkg-algumacoisa ou apt-outracoisa que existem na distribuição?
Por último: distribuições erigidas em cima do Debian como Ubuntu, Knoppix e Linspire funcionam. Pra que mudar isso? Se você não quer usar um dos três debians (stable, testing ou unstable), use essas distribuições. Vai continuar podendo usar os pacotes...
--
Ainda em estágio altamente experimental e pré-alpha: http://linuxfud.org
LinuxFUD, mostrando as mentiras da mídia contra o software livre!
Comentário de Manoel Pinho
15/03/05 20:36 - usuário registrado #8
@Andre: Mas pelo que eu sei esse rpm no debian não compartilha a mesma "base de dados" com o dpkg, não checando por exemplo se um determinado arquivo de um rpm sobrescreve outro de algum pacote .deb.
Além da conversão com o Alien e o uso do rpm no próprio Debian, há alguma forma mais integrada de usar rpms e .debs ?
Além da conversão com o Alien e o uso do rpm no próprio Debian, há alguma forma mais integrada de usar rpms e .debs ?
Comentário de Marco Aurélio
15/03/05 21:19
> Segundo Langasek, isto vai: > Segundo Langasek, isto vai reduzir drasticamente as necessidades
> de coordenação entre arquiteturas, e possivelmente reduzir o ciclo
> de lançamentos para uma ordem de 12 a 18 meses.
Sinceramente, este é um grande tiro no pé. E nada inteligente. A quantidade de computadores Sparc é _muito_ maior que IA-64: a próprio Intel se arrepende do IA-64. E ARM é proeminente, todo dispositivo embarcado utiliza Sparc.
O problema é: o Debian não está dando conta do serviço de manter tantas arquiteturas. Imagino até que, de certa forma, eles se veem ameaçados por distros derivadas dele, motivando uma migração de usuários indesejada. Concentrando em algumas poucas arquiteturas, ou seja, reduzindo o tamanho do problema, eles esperam resolver a questão. No entanto, eles estão restringindo _demais_.
Existem lugares em que Debian é utilizado justamente por essa diversidade: a mesma distro, em computadores de arquiteturas diferentes. Isso é legal, facilita a vida das pessoas. Agora, se o Debian parar de suportar tanta arquitetura, muita gente vai preferir migrar para outra distro de uma vez, já que em x86 Debian está _LONGE_ de ser a melhor.
> de coordenação entre arquiteturas, e possivelmente reduzir o ciclo
> de lançamentos para uma ordem de 12 a 18 meses.
Sinceramente, este é um grande tiro no pé. E nada inteligente. A quantidade de computadores Sparc é _muito_ maior que IA-64: a próprio Intel se arrepende do IA-64. E ARM é proeminente, todo dispositivo embarcado utiliza Sparc.
O problema é: o Debian não está dando conta do serviço de manter tantas arquiteturas. Imagino até que, de certa forma, eles se veem ameaçados por distros derivadas dele, motivando uma migração de usuários indesejada. Concentrando em algumas poucas arquiteturas, ou seja, reduzindo o tamanho do problema, eles esperam resolver a questão. No entanto, eles estão restringindo _demais_.
Existem lugares em que Debian é utilizado justamente por essa diversidade: a mesma distro, em computadores de arquiteturas diferentes. Isso é legal, facilita a vida das pessoas. Agora, se o Debian parar de suportar tanta arquitetura, muita gente vai preferir migrar para outra distro de uma vez, já que em x86 Debian está _LONGE_ de ser a melhor.
Comentário de Leandro
15/03/05 22:02 - usuário registrado #447
Defina isso:
já que em x86 Debian está _LONGE_ de ser a melhor.
Ok, defina "melhor".
Leandro
já que em x86 Debian está _LONGE_ de ser a melhor.
Ok, defina "melhor".
Leandro
Comentário de André Luís Lopes
15/03/05 22:08
O gerenciador de pacotes RPM: O gerenciador de pacotes RPM "rpm" existente no Debian é o mesmo gerenciador de pacotes RPM que qualquer outra distribuição baseada em pacotes RPM utiliza, portanto, se o RPM oficial não possui esse suporte, o que se encontra disponível no Debian (que na verdade é o mesmo) também não possui.
Como disse no meu comentário inicial, *não* é uma boa idéia utilizar pacotes RPM em um sistema baseado em Debian porque, como você mesmo citou, as bases de dados de pacotes dos dois gerenciados não tem conhecimento uma da outra. Isso está até mesmo citado na descrição do próprio pacote .deb do "rpm" disponível no Debian.
O alien pode ser uma opção, mas nem sempre funciona 100%. Eu utilizei o alien pouquíssimas vezes, basicamente quando precisei converter um pacote RPM de um antivírus comercial que era distribuído somente em formato RPM e (por ser comercial) não fornecia o código-fonte para ser empacotado em formato .deb .
Quanto a maneiras mais integradas, não conheço nenhuma. Talvez o "Smart" (sendo desenvolvido pelo pessoal da Conectiva) seja uma opção, mas não conheço muito sobre ele para ter uma opinião formada sobre o mesmo.
De qualquer forma, o "Smart" já está disponível como um pacote Debian no Debian sid/unstable caso você queira testá-lo. Mas não é algo suportado oficialmente pelo Debian.
Como disse no meu comentário inicial, *não* é uma boa idéia utilizar pacotes RPM em um sistema baseado em Debian porque, como você mesmo citou, as bases de dados de pacotes dos dois gerenciados não tem conhecimento uma da outra. Isso está até mesmo citado na descrição do próprio pacote .deb do "rpm" disponível no Debian.
O alien pode ser uma opção, mas nem sempre funciona 100%. Eu utilizei o alien pouquíssimas vezes, basicamente quando precisei converter um pacote RPM de um antivírus comercial que era distribuído somente em formato RPM e (por ser comercial) não fornecia o código-fonte para ser empacotado em formato .deb .
Quanto a maneiras mais integradas, não conheço nenhuma. Talvez o "Smart" (sendo desenvolvido pelo pessoal da Conectiva) seja uma opção, mas não conheço muito sobre ele para ter uma opinião formada sobre o mesmo.
De qualquer forma, o "Smart" já está disponível como um pacote Debian no Debian sid/unstable caso você queira testá-lo. Mas não é algo suportado oficialmente pelo Debian.
Comentário de André Luís Lopes
15/03/05 22:20
Exato. A *melhor* distribuiç: Exato. A *melhor* distribuição para mim pode (e provavelmente é) ser bem diferente da melhor distribuição para você. Não que eu esteja dizendo que Debian é a melhor distribuição do mundo para todos os casos.
Pessoalmente, acho que Debian puro para desktops pode não ser a melhor escolha. Também acho que é problemático para usuários menos experientes (e, as vezes, até para alguns usuários mais experientes) conseguir utilizar Debian em servidores que utilizem hardware mais atual.
Porém, *para mim*, os benefícios que tenho com a utilização de Debian para servidores compensam esses problemas facilmente. Novamente, isso é algo que *eu* vejo. Todos tem o direito de ter uma visão completamente diferente da minha e essa é a grande vantagem de sermos livres para escolher o que queremos utilizar. Somos livres para fazê-lo.
E sobre o comentário de eliminar Sparc ser um tiro no pé e manter ia64 ser ainda outro (eu sei, não foi dito exatamente isso, mas estou resumindo a coisa toda), novamente : trata-se de uma *proposta* e não de algo já decidido.
As arquiteturas que serão realmente removidas (se é que serão) ainda serão decididas. A proposta somente dá exemplos com base na situação no momento em que a mesma foi escrita, mas o estado dos build-daemons é bastante dinâmico e pode mudar completamente de um dia para outro.
Pessoalmente, acho que Debian puro para desktops pode não ser a melhor escolha. Também acho que é problemático para usuários menos experientes (e, as vezes, até para alguns usuários mais experientes) conseguir utilizar Debian em servidores que utilizem hardware mais atual.
Porém, *para mim*, os benefícios que tenho com a utilização de Debian para servidores compensam esses problemas facilmente. Novamente, isso é algo que *eu* vejo. Todos tem o direito de ter uma visão completamente diferente da minha e essa é a grande vantagem de sermos livres para escolher o que queremos utilizar. Somos livres para fazê-lo.
E sobre o comentário de eliminar Sparc ser um tiro no pé e manter ia64 ser ainda outro (eu sei, não foi dito exatamente isso, mas estou resumindo a coisa toda), novamente : trata-se de uma *proposta* e não de algo já decidido.
As arquiteturas que serão realmente removidas (se é que serão) ainda serão decididas. A proposta somente dá exemplos com base na situação no momento em que a mesma foi escrita, mas o estado dos build-daemons é bastante dinâmico e pode mudar completamente de um dia para outro.
Comentário de Smart
16/03/05 0:18
.deb , rpm , smart:
Eu andei utilizando o smart no Debian. Funciona direitinho, so tem alguns incovenientes, como marcar como dependencia um pacote 'Sugestao'.
Tb como é escrito em python, maquinas antigas nem pensem em utiliza-lo.
Acho que deveriam olhar mais este Smart... Bem interessante.
Eu andei utilizando o smart no Debian. Funciona direitinho, so tem alguns incovenientes, como marcar como dependencia um pacote 'Sugestao'.
Tb como é escrito em python, maquinas antigas nem pensem em utiliza-lo.
Acho que deveriam olhar mais este Smart... Bem interessante.
Comentário de Smart
16/03/05 0:19
.deb , rpm , smart:
Eu andei utilizando o smart no Debian. Funciona direitinho, so tem alguns incovenientes, como marcar como dependencia um pacote 'Sugestao'.
Tb como é escrito em python, maquinas antigas nem pensem em utiliza-lo.
Acho que deveriam olhar mais este Smart... Bem interessante.
Mas p/ o caso do Debian ( q so testei nele ) ainda faltam algumas coisinhas q os instaladores padroes tem.
Eu andei utilizando o smart no Debian. Funciona direitinho, so tem alguns incovenientes, como marcar como dependencia um pacote 'Sugestao'.
Tb como é escrito em python, maquinas antigas nem pensem em utiliza-lo.
Acho que deveriam olhar mais este Smart... Bem interessante.
Mas p/ o caso do Debian ( q so testei nele ) ainda faltam algumas coisinhas q os instaladores padroes tem.
Comentário de anonimo
16/03/05 0:49
Dieta: Não sou contra um grande portifolio de pacotes pre-compilados do Debian. Mas distribuir este portifolio junto, em cada release, com o core não me parece uma boa ideia. 7 cds e um dvd a cada release ? Quem aguenta baixar isto tudo. E beta testes, 7 cds e um dvd para cada release beta ? Quem aguenta isto ? E não falo so do Debian, a maioria das distribuições fazem este tipo (big) de release.
Não seria mais facil lançar um unico cd (ou uma iso para download, zipada, se possivel) com o core - tudo necessario para rodar com segurança um Debian console (Isto não dá mais que 150 mega) e mais um desktop a escolha do fregues: KDE ou Gnome. Os outros W. Managers são pequenos e podem ser baixados da net. O Kurumim era assim, tudo e mais um pouco em 200 mega.
Eu adoraria ser beta tester, mas não de distros de 3 ou mais cds por release. O Kurumim já vai seguindo neste caminho. Era uma distro de 200 mega, agora está chegando aos 400 megas. Quem vai ser beta tester nestas condições?
Não seria mais facil lançar um unico cd (ou uma iso para download, zipada, se possivel) com o core - tudo necessario para rodar com segurança um Debian console (Isto não dá mais que 150 mega) e mais um desktop a escolha do fregues: KDE ou Gnome. Os outros W. Managers são pequenos e podem ser baixados da net. O Kurumim era assim, tudo e mais um pouco em 200 mega.
Eu adoraria ser beta tester, mas não de distros de 3 ou mais cds por release. O Kurumim já vai seguindo neste caminho. Era uma distro de 200 mega, agora está chegando aos 400 megas. Quem vai ser beta tester nestas condições?
Comentário de alan
16/03/05 1:49 - usuário registrado #89
Você não precisa baixar tod: Você não precisa baixar todos os cds para testar a distribuição. Todos os pacotes estão *sempre* disponíveis para download.
Você pode até ajudar a testar o instalador e ser um beta-tester baixando uma imagem que inclui o básico (104MB) ou ainda uma outra imagem que irá baixar todo o sistema pela internet.
Uma coisa é certa: o Debian é a distribuição que possui mais mitos a serem quebrados!
--
Alan Kelon Oliveira de Moraes
Você pode até ajudar a testar o instalador e ser um beta-tester baixando uma imagem que inclui o básico (104MB) ou ainda uma outra imagem que irá baixar todo o sistema pela internet.
Uma coisa é certa: o Debian é a distribuição que possui mais mitos a serem quebrados!
--
Alan Kelon Oliveira de Moraes
Comentário de VIcente
16/03/05 8:11
Nadando contra corrente: Discordo,
uma das grandes vantagens do Debian é a variedade e qualidade.
Existe Debian para todos os gostos (estável, teste e "instável") existem pacotes para todos tipo de necessidades e funcionalidades.
O Debian não precisa ficar disputando lugar com as outras distribuições.
O Debian é o Debian (quero dizer que ele já tem seu lugar ao sol :)
Quem vai dizer o que é importante e o que é supérfluo?
Recentemente nós tivemos a notícia que Linus Torvalds adotou o PowerPC para o seu desktop. Sabe qual foi o seu comentário? Ele disse: "já tem muitas pessoas testando x86". Acho que é do seu interesse (dele) que o Linux continue sendo portável para as mais diversas arquiteturas.
Alguns sistemas operacionais são muito limitados com relação a portabilidade...
Um abraço a todos.
uma das grandes vantagens do Debian é a variedade e qualidade.
Existe Debian para todos os gostos (estável, teste e "instável") existem pacotes para todos tipo de necessidades e funcionalidades.
O Debian não precisa ficar disputando lugar com as outras distribuições.
O Debian é o Debian (quero dizer que ele já tem seu lugar ao sol :)
Quem vai dizer o que é importante e o que é supérfluo?
Recentemente nós tivemos a notícia que Linus Torvalds adotou o PowerPC para o seu desktop. Sabe qual foi o seu comentário? Ele disse: "já tem muitas pessoas testando x86". Acho que é do seu interesse (dele) que o Linux continue sendo portável para as mais diversas arquiteturas.
Alguns sistemas operacionais são muito limitados com relação a portabilidade...
Um abraço a todos.
Comentário de pedr0
16/03/05 11:20 - usuário registrado #181
Nao ta dando conta ...: Primeiro a mozilla foundation descontinuando o seamonkey, agora isso ... sei la, a impressao q da eh q o open source ta crescendo mais do q esperavam ; )
Comentário de Anônimo
16/03/05 14:20
Patola, como cortar arquite: Patola, como cortar arquiteturas afeta esse monte de derivadas todas feitas pra rodar em x_86?
Comentário de semente
18/03/05 0:50 - usuário registrado #147
Cessar suporte?: Bom, não foi o que li agora na Debian Weekly News:
Planos de Lançamento Pós-Sarge. Steve Langasek anunciou [27]planos
para o lançamento após o sarge que incluem dividir o repositório
Debian em um componente regular e um de segunda classe com
arquiteturas usadas menos freqüentemente. Isto deve reduzir o espaço
para espelhamento e o tempo necessário para manter a testing em forma,
já que ela conterá menos arquiteturas
27. http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
Bom, pelo que entendi seria uma melhor divisão, não?
--
Guilherme Mesquita Gondim (semente)
Movido a Debian GNU/Linux e anarquismo!
# aptitude install anarchism
Planos de Lançamento Pós-Sarge. Steve Langasek anunciou [27]planos
para o lançamento após o sarge que incluem dividir o repositório
Debian em um componente regular e um de segunda classe com
arquiteturas usadas menos freqüentemente. Isto deve reduzir o espaço
para espelhamento e o tempo necessário para manter a testing em forma,
já que ela conterá menos arquiteturas
27. http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
Bom, pelo que entendi seria uma melhor divisão, não?
--
Guilherme Mesquita Gondim (semente)
Movido a Debian GNU/Linux e anarquismo!
# aptitude install anarchism
Comentário de Leo Lopes
18/03/05 6:14
Sparc é sacanagem?: Não sei porque... já que trabalho com vários servidores Sun Sparc e posso dizer sem sombra de dúvida que são muito bons, muito melhores que qualquer arquitetura ix86, mesmo as de 64 bits.
Se continuasse do jeito que estava corria o risco de continuar eternamente mais como uma meta-distribuição (usada para fazer outras distribuições mais especializadas como Ubuntu, Linspire, Knoppix, Kurumin e cia, etc) do que como uma distribuição.
Por causa do longo ciclo entre o lançamento das versões estáveis, o Debian disperdiçou muitas oportunidades para uma maior popularização, tanto que têm surgido várias distribuições derivadas como o Ubuntu, os CDDs e outras que tentam fornecer alternativas a isso.
O Debian tem tudo para ser a distribuição mais popular quando concentrar os seus esforços e resolver algumas coisas que atraem os usuários para outras distribuições. A melhoria no instalador foi um primeiro e grande passo.