Canonical considerando versões "rolling releases" ao invés do ciclo de 6 meses?

[Sergio Benjamim]

Vou ficar só na versão alfa/beta agora.

kkkkkkkkkkkkkkk

Senti uma indireta aí... hehe. Muita gente vai acabar ficando numa versão alfa/beta sem querer... eu vou de LTS.

[rudregues]

para as versões normais, eu iria por exemplo instalar o 14.10 e ir atualizando pro 15.04 e depois pro 15.10, mas se fosse ir pro 16.04 LTS teria que baixar a iso dele e instalar? Seria possível também instalar a 14.04 LTS e depois ir atualizando até o 15.10 do mesmo jeito?

Não, nada disso. As versões 13.04 e 13.10 seriam as últimas intermediárias; depois seria 14.04 LTS, 16.04 LTS, 18.04 LTS e assim por diante.

Entendi eliseu, então na verdade eu pego o 14.04 LTS e vou atualizando por até cinco anos com suporte da Canonical, sendo que a cada dois anos posso baixar a iso da versão mais recente e fazer a mesma coisa se assim desejar.
Pra mim seria ótimo. Uso Sabayon 10 desde o ano passado, também usei o 9 e ele é rolling release, comecei com o nove e ele foi sendo atualizado tranquilamente até o 10. É estável e atualizado, na minha opinião o Ubuntu tem muito a ganhar com isso também pro lado dos desenvolvedores, que poderão focar melhor em algumas versões. Uma coisa que seria diferente do Ubuntu em relação ao Sabayon na minha opinião, é que haveria um número menor de atualizações no Ubuntu, pois o Sabayon coloca software novo mesmo (quase um bleeding edge).

  [ ]'s

[Joseph]

Seria a melhor coisa que a Canonical faria, pois a cada nova versão surgem bugs atrás de bugs, adotar versões rolling releases seria uma maravilha, muitas distros estão se utilizando desse recurso, e estão ótimas, o que deveriam adotar também seria alguns recursos do Fedora, se não me engano, que atualiza apenas as partes do pacote onde continham os bugs, ou novas versões, sem ter que baixar o pacote inteiro.

[eliseu_carvalho]

Mas aí seria o caso de trocar DEB por RPM, e isso significaria recomeçar o Ubuntu do zero, descartando tudo o que já foi feito em quase 10 anos de história do sistema.

[MatheusWillder]

Já havia dito aqui que acho exagero um sistema lançado a cada seis meses, é pouco tempo e muitas novidades que deveriam ser lançadas não aparecem por estarem inacabadas, sendo lançado um sistema incompleto, e infelizmente, são sempre as versões mais novas que são recomendadas para o download, um usuário leigo não sabe distinguir uma LTS de uma versão beta comum.

Também já passei dos dias em que eu uso cada nova versão, e acho que muitos aqui já deixaram isso também. A Canonical deveria lançar versões de testes, mas sem prazo determinado para os lançamentos nem suporte para essas versões, os heavy users poderiam instalar essas versões betas normalmente, não?

Acho que a Canonical deve estar amadurecendo, afinal.

[rudregues]

Seria a melhor coisa que a Canonical faria, pois a cada nova versão surgem bugs atrás de bugs, adotar versões rolling releases seria uma maravilha, muitas distros estão se utilizando desse recurso, e estão ótimas, o que deveriam adotar também seria alguns recursos do Fedora, se não me engano, que atualiza apenas as partes do pacote onde continham os bugs, ou novas versões, sem ter que baixar o pacote inteiro.

É a tecnologia de pacotes delta. No meu Sabayon habilitei-a pra economizar banda de internet. A distro OpenSuse por exemplo tem a tecnologia implementada oficialmente.

Mas aí seria o caso de trocar DEB por RPM, e isso significaria recomeçar o Ubuntu do zero, descartando tudo o que já foi feito em quase 10 anos de história do sistema.

Existe uma implementação em sistemas Debian, chamada debdelta http://www.vivaolinux.com.br/dica/Conhecendo-e-usando-o-debdelta que usa o apt-get. Não precisa descartar. O problema pelo que me lembro, é que os pacotes precisam ser reescritos pra suportar a tecnologia. Dá muito trabalho. Quem tiver curiosidade e souber ler em inglês, dá uma olhada aqui https://wiki.ubuntu.com/UbuntuDebdeltaSupport pra ter alguns detalhes.

  [ ]'s

[rudregues]

O que eu me pergunto, é sobre que atualizações serão feitas e com que frequência. Como serão versões LTS imagino que só serão lançadas as atualizações que foram razoavelmente testadas e apresentaram boa compatibilidade entre dependências novas e antigas. Acho que teremos pacotes mais novos do que temos atualmente, mas não muito novos como o Arch Linux que coloca os mais recentes, mesmo que ainda estejam instáveis ou não tenham sido muito testados.

Aliás, se o Ubuntu aumentar demais o número de atualizações em relação ao número atual, seria bem interessante os servidores de lá suportaresm os pacotes delta. Principalmente pra quem num tem a net tão rápida que nem eu!

Alguém sabe quando a Canonical tem planos de liberar mais informações sobre isso? Talvez na próxima Ubuntu development summit?

  [ ]'s

[niquelnausea]

isso ta mais para um half rolling release, já que a ideia do rolling release é estar sempre com a versão mais atual, existindo apenas mídias de instalação com pacotes mais recentes. sou totalmente a favor dessa ideia, mas fiquei na duvida de como vai ser o período de desenvolvimento entre as versões, se vai existir o ubuntu 14.04 estável e o ubuntu 16.04 testing?

sobre o uso da tecnologia delta, não ha a necessidade de se reescrever os programas, já que o delta apenas cria a diferença entre o pacote 1 e pacote 2, por exemplo, através dos pacotes firefox17 e firefox18, ele cria um terceiro pacote firefox17-18, ou seja, com os pacotes firefox17 mais o firefox17-18 ele cria o pacote firefox18, normalmente o pacote firefox17-18 é bem pequeno, e isso é o que gera a economia no download, mas traz o inconveniente da necessidade de se ter o pacote firefox17 no cache /var/cache/apt/archives.

[eliseu_carvalho]

se vai existir o ubuntu 14.04 estável e o ubuntu 16.04 testing?

Se é o que eu entendi, a partir da versão 14.04 LTS, todas as novas versões seriam estáveis.

[garfo]

mas fiquei na duvida de como vai ser o período de desenvolvimento entre as versões, se vai existir o ubuntu 14.04 estável e o ubuntu 16.04 testing?

As versões estáveis passariam ser somente as versões LTS (14.04, 16.04, 18.04, e assim vai...).

O resto (versões começadas com números ímpares ou terminadas em .10, por ex: a 15.04, a 14.10) ficaria só nas daily builds, ou seja, cada dia teria uma iso nova pra baixar. Com isso a equipe da Canonical tem mais tempo e mais liberdade para testar coisas novas e até correções que poderiam vir numa próxima versão LTS.

Eu torço para que o Mark leve isso a diante. É uma ideia ótima, e aparentemente, pelo que li, a maioria da comunidade gostou. 

[rudregues]

isso ta mais para um half rolling release, já que a ideia do rolling release é estar sempre com a versão mais atual, existindo apenas mídias de instalação com pacotes mais recentes. sou totalmente a favor dessa ideia, mas fiquei na duvida de como vai ser o período de desenvolvimento entre as versões, se vai existir o ubuntu 14.04 estável e o ubuntu 16.04 testing?

sobre o uso da tecnologia delta, não ha a necessidade de se reescrever os programas, já que o delta apenas cria a diferença entre o pacote 1 e pacote 2, por exemplo, através dos pacotes firefox17 e firefox18, ele cria um terceiro pacote firefox17-18, ou seja, com os pacotes firefox17 mais o firefox17-18 ele cria o pacote firefox18, normalmente o pacote firefox17-18 é bem pequeno, e isso é o que gera a economia no download, mas traz o inconveniente da necessidade de se ter o pacote firefox17 no cache /var/cache/apt/archives.

Concordo com o que diz de estar mais para half rolling release, uma vez que serão ciclos de 5 anos de atualizações pra cada LTS, mas não entendo o que quer dizer com "não precisa criar pacotes novos". Vamos supor que do firefox 17 para o 18 as diferenças são alguns ícones e um bug corrigido. Como o apt-get faria para pegar esses ícones e essa correção do arquivo firefox18.deb e baixarpra instalar? Que eu saiba, o apt-get baixa o firefox18.deb por inteiro e instala. Para que usasse o delta, teria que ter um firefox18.deb "quebrado" em vários pacotes, tipo firefox18_ícones.deb e firefox18_bugcorrigido.deb?

Pergunto isso, porque no Sabayon é mais ou menos assim que é feito, são baixados pacotes .edelta durantes a atualização com pacotes delta. E também, porque no link do vivaolinux que passei, o autor ensina um comando que cria pacotes utilizando o pacote novo e o antigo. Por isso imaginei que o servidor teria que criar e fornecer estes arquivos para o usuário baixar. Não faria sentido a gente baixar os dois pacotes e criar o pacote delta. O comando é esse inclusive:

# debdelta pacote_versão_anterior.deb pacote_versão_atual.deb pacote.debdelta

Tentei ler na documentação oficial do debdelta a parte de repositórios, mas achei confuso... http://debdelta.debian.net/html/x65.html#repo_howto

  [ ]'s

[niquelnausea]

isso ta mais para um half rolling release, já que a ideia do rolling release é estar sempre com a versão mais atual, existindo apenas mídias de instalação com pacotes mais recentes. sou totalmente a favor dessa ideia, mas fiquei na duvida de como vai ser o período de desenvolvimento entre as versões, se vai existir o ubuntu 14.04 estável e o ubuntu 16.04 testing?

sobre o uso da tecnologia delta, não ha a necessidade de se reescrever os programas, já que o delta apenas cria a diferença entre o pacote 1 e pacote 2, por exemplo, através dos pacotes firefox17 e firefox18, ele cria um terceiro pacote firefox17-18, ou seja, com os pacotes firefox17 mais o firefox17-18 ele cria o pacote firefox18, normalmente o pacote firefox17-18 é bem pequeno, e isso é o que gera a economia no download, mas traz o inconveniente da necessidade de se ter o pacote firefox17 no cache /var/cache/apt/archives.

Concordo com o que diz de estar mais para half rolling release, uma vez que serão ciclos de 5 anos de atualizações pra cada LTS, mas não entendo o que quer dizer com "não precisa criar pacotes novos". Vamos supor que do firefox 17 para o 18 as diferenças são alguns ícones e um bug corrigido. Como o apt-get faria para pegar esses ícones e essa correção do arquivo firefox18.deb e baixarpra instalar? Que eu saiba, o apt-get baixa o firefox18.deb por inteiro e instala. Para que usasse o delta, teria que ter um firefox18.deb "quebrado" em vários pacotes, tipo firefox18_ícones.deb e firefox18_bugcorrigido.deb?

Pergunto isso, porque no Sabayon é mais ou menos assim que é feito, são baixados pacotes .edelta durantes a atualização com pacotes delta. E também, porque no link do vivaolinux que passei, o autor ensina um comando que cria pacotes utilizando o pacote novo e o antigo. Por isso imaginei que o servidor teria que criar e fornecer estes arquivos para o usuário baixar. Não faria sentido a gente baixar os dois pacotes e criar o pacote delta. O comando é esse inclusive:

# debdelta pacote_versão_anterior.deb pacote_versão_atual.deb pacote.debdelta

Tentei ler na documentação oficial do debdelta a parte de repositórios, mas achei confuso... http://debdelta.debian.net/html/x65.html#repo_howto

  [ ]'s

não existe a necessidade de se criar vários pacotes, já que o pacote firefox17.deb seria um binário, e o xdelta criaria um arquivo com apenas a diferença (um pacote com alguns kb). quando se cria um arquivo que contem apenas as diferenças (firefox17-18.xdelta) entre dois pacotes (firefox17.deb e firefox18.deb), ele funcionaria apenas se o pacote mais antigo já estivesse no cache, do contrario o apt iria baixar apenas a versão mais atual. caso exista nos repositórios apenas o arquivo firefox17-18.xdelta e você tenha apenas uma versão mais antiga no cache (firefox16.deb por exemplo), o apt ira baixar o pacote firefox18.deb, mas caso seja disponibilizado o pacote firefox16-18.xdelta, o apt iria baixar apenas a diferença entre eles e criara o pacote firefox18.deb. infelizmente em alguns casos esse arquivo .xdelta tem quase o mesmo tamanho do arquivo original, inviabilizando esse método de atualização.

[dicadavid]

tomara que seja uma decisao bem pensada... mantem as LTS e apos 11 meses ou 18 lanca uma atualização da iso, por exemplo se saiu a versao X.04, a nova seria X.04.1, para que reconheca hardware lancados neste periodo.

[nomade]

Vou ficar só na versão alfa/beta agora.

Se esse plano da Canonical for adotado não terá versões alfa/beta, apenas daily builds, como já está acontecendo com o Raring Ringtail. Rolling release em sentido pleno!

Pra não restar dúvidas:

Versões normais: rolling release (daily builds até sair a próxima versão LTS)
Versões LTS: lançadas a cada dois anos, a partir do congelamento de um daily build considerado estável o bastante em uma data estabelecida.

É verdade.
A questão é se será simples um upgrade do Gnone, por exemplo.

Pois é... fico pensando que isso vai fazer com que para ter versões novas de alguns softwares só através de PPAs. Isso costuma gerar instabilidade também, a galera acha que instabilidades vem só do fato de lançarem versões a cada 6 meses e esquecem que teriam que ficar com a mesma versão de vários softwares por 2 anos... 2 anos... 2 anos...
Não sei se alguém notou, mas o LibreOffice, por exemplo, melhorou para bem melhor nos últimos 2 anos. Mas até que ele pode ser atualizado por PPA sem sustos. Já o audacity, que eu uso muito... já me deu sustos, por isso nada de PPA pra ele.

[Renan Rischiotto]

Eu acharia muito bom isso!!
Só usar LTS!!