A história é cíclica...

Hoje li uma notícia que me fez voltar lá para 2008... Vendo as novidades do Funtoo 1.3 me deparo com o comentário que não haverá mais suporte multilib, se quiser suporte a pacotes 32bits (Olá Steam! Olá jogos nostálgicos via wine!) terá que fazer um chroot dentro do sistema! Na discussão Daniel Robbins relata que o trabalho é muito maior em manter o sistema multilib e que pode se concentrar em otimizações para 64 bits.
O que mais me chama a atenção é:
- Uma sensação de pressa em retirar esse suporte, no próprio site do funtoo diz que estão trabalhando na idéia de um contâiner 32, por quê não esperar sair esse contâiner antes de simplesmente retirar a versão?
- Se tá ruim para uma meta-distro, imagina para um Debian, Fedora, Suse da vida que compila tudo para várias arquiteturas. Será que a moda pega?
- Será o início dos Frankensteins de Distros 64 com contâiner de outra Distro?
- Se quiser o máximo de desempenho, valeria pacotes i686 mais que i386? Tem distros que ainda mantém suporte 32 e empacotamento i686?
- Chroot ou docker?
O que me dizem?

https://www.funtoo.org/Release_Notes/1.3-release

O Daniel é um cara inteligente, se ele simplesmente começasse a trabalhar nesse projeto de container com gpu passtrough a comunidade do Funtoo ia possivelmente cagar e andar mas como ele matou o suporte a 32 bit o tal container se torna uma quase necessidade e ganha mais apoio.

Com pacotes Snap e semelhantes, acho até que faz algum sentido. Se a aplicação precisa de bibliotecas de 32 bits, ela que traga as suas, e as coloque dentro do seu container.

O problema para nós usuários seria o bloat de disco. Parece que todo mundo assume que “disco é barato”. Mas talvez seja mesmo... se a gente contabilizar o tempo total gasto naqueles problemas cabeludos com versões incompatíveis de bibliotecas, especialmente na presença de aplicações antigas/legadas, e contar isso em real por homem-hora, talvez a área adicional em disco se pague muito rapidamente.

Fora isso, dar um basta ao pleno suporte à arquitetura mais velha é um incentivo a mais à modernização das aplicações, com ganhos para todo mundo.


... “Principium sapientiae timor Domini, et scientia sanctorum prudentia.” (Proverbia 9:10)

Não tinha pensado nos pacotes universais, mas acho que ainda tem que aprimorá-los bastante para que sejam mais rápidos, alguns programas como snap já fizeram a galera reclamar do tempo de boot do Ubuntu, toda a estrutura 32 pra rodar um novo ou uma aplicação de Áudio e vídeo seria bem complicado.

Já vi que tem container de Ubuntu 32 no Rocker o que facilita muito a vida!

Concordo, queimando a ponte só dá a opção de ir para frente, mas também pode perder usuários, na pior das hipóteses colaboradores.

Havia uma tradição de manter a compatibilidade da tecnologia nova com a velha. A nova trazia um plus e ainda suportava a velha, mantendo o investimento feito.
Isso vem se perdendo. O novo "mais novo" nem sempre, ou melhor, quase nunca suporta o velho, obrigando o usuário a reinvestir para migrar.
Há sempre resistência. Ainda é possível comprar com alguma facilidade uma fita k7, mas um tocador para ela quase não se encontra. E os discos analógicos voltaram, com preços salgados.



__________________________________
Linux Registered User nº 439378
Ubuntu Forum Member Since Nov/07/2006
VOL Member SInce Jul/01/2008

Eu sou um daqueles que acho que já está demorando demais para que todos migrem para o 64
óbviu que o 32bits está vivo ainda por causa de empresas e sistemas únicos perdidos por ai, mas um grande culpado disso na área de desktop é o maldito steam que ainda não lançou a porcaria do steam64

E com certeza as pessoas focando somente em 64bits tudo mundo sairia ganhando, espero que isso ocorra logo
- - - - -
www.gitlab.com/grinder
www.github.com/ericfernandesferreira
www.youtube.com/candelabrus1

Compatibilidade — ou a falta dela — é uma das principais razões por que nós hoje usamos AMD64 em vez de Itanium, tanto nos nossos PCs quanto nos servidores das nossas empresas.

Mas a compatibilidade tem um custo. Os processadores precisam incorporar mais microcircuitos do que teriam de ter se a compatibilidade não existisse, esquentando mais e possivelmente operando em velocidade menor do poderiam.

A mesma coisa com os nossos sistemas operacionais. Ser compatíveis com o passado é o que os faz aceitos, e também é o que lhes acrescenta peso e, em muitos casos, prejudica seu desempenho.


... “Principium sapientiae timor Domini, et scientia sanctorum prudentia.” (Proverbia 9:10)

Na verdade, não há a necessidade de criar uma solução nova para isso. LXD e Docker já possuem as capacidades necessárias, dá para rodas jogos de dentro de contêineres LXD como SuperTuxKart ou Warzone 2100, o que eu testei até agora de jogos, e Chromium usando VAAPI para acelerar vídeo por hardware.

Creio que seja menos trabalho adaptar uma solução usando LXD ou Docker que criar uma solução nova. Ambas já funcionam muito bem.

O Steam é complicado, ele em si pode ser 64, mas nessa toada talvez ele tenha que agregar um container para rodar jogos 32. Finalmente para o Desktop a gente consegue uma aproximação da biblioteca de jogos dos Windows (as vezes até mais fácil rodar jogos antigos via wine), então começamos o boicote de dificultar o acesso a essa biblioteca

Mexi pouco no Docker, nem encostei no LXD... Vou aprender, mas enquanto isso fiz o que eu mais conheço, usei um debootstrap do Debian Buster 32 e deixei rodando o lutris e a Steam, fiz um backup e um script de acesso rápido.... Velhos costumes

Concordo, agora que já garanti meu acesso a 32bis (descrito na resposta acima) tô querendo instalar o sistema pure64 e fazer uns benchmarks