Mudança na glibc atrapalha som no Fedora, e Linus Torvalds oferece um fix
A thread de discussão deste bug do Fedora é interessante:
- surge um bug no som,
- com a participação de Linus Torvalds, usuário do Fedora, os desenvolvedores identificam que o erro passou a acontecer após uma mudança de comportamento da glibc,
- o responsável pela glibc no projeto diz que a mudança foi na glibc mas os programas que dependiam do comportamento antigo dela é que estão errados,
- o responsável pela glibc no projeto “fecha” o registro, marcando-o como um não-bug.
- Linus questiona sobre a política em relação a alterações em comportamento que gerem regressões, e o desenvolvedor mantém sua posição,
- mimimi à parte, o erro no som continua acontecendo.
Seria apenas um interessante exemplo da dinâmica do desenvolvimento destes softwares, mas logo em seguida aconteceu um complemento que tornou tudo mais pitoresco: na ausência de uma solução gerada por quem expôs o problema, o próprio Linus (que não é desenvolvedor do Fedora e nem da glibc) postou na mesma thread uma solução temporária (para usar enquanto os responsáveis não resolverem), baseada em compilar meia dúzia de linhas em C para remover a regressão, e aí chamar o navegador com um comando que garante que esta meia dúzia de linhas vai ser usada para modificar o comportamento da glibc.
A julgar pelos comentários agradecidos de quem apareceu depois, pelas novas versões e instruções de instalação do remendo torvaldiano, ele resolveu mesmo – e ainda questionou com argumentos sólidos (medição de desempenho) se há alguma vantagem nessa alteração da glibc.
Em tempo: os desenvolvedores da glibc não estão enganados quanto a só haver erro caso os desenvolvedores dos outros softwares tenham feito uso de um recurso que a glibc anteriormente permitia, mas que a documentação explicitamente orientava a não usar – portanto faz sentido esperar que os desenvolvedores que fizeram uso do recurso lancem novas versões modificadas em breve – e enquanto isso não acontecer, é possível que o problema seja percebido em mais distribuições e em mais sistemas – já há suspeita de que ele tenha sido percebido também em comportamentos erráticos do squashfs recentemente.
(via lwn.net)
@brlinuxblog
Feed RSS
Isso lembra um pouco toda aquela discussão do ext4. Ainda bem que desta vez o Linus interveio.
Provavelmente ele utiliza o Fedora, é bom isso.
O Linus é muito sensato. Se não fosse ele, acho que o Linux nunca teria evoluido como evoluiu.
Agora esse desenvolvedor da glibc é muito orgulhoso e isso abre a discussão do quanto TODO o Linux em geral (todas a distros) podem derrepende terem problemas por causa de um desenvolvedor orgulhoso que não adimite estar errado e que cuida do desenvolvimento de partes básicas mas essenciais como as bibliotecas em C em que praticamente todos os programas dependem. Dá medo isso.
Alguma coisa deve ser mudado nesse esquema de desenvolvimento. Partes basicas mas essenciais como essa não podem NUNCA ficar o seu desenvolvimento na mão de somente uma pessoa.
Não sei se interessa, mas explicando de forma um pouco mais técnica ele fez uma implementação da memcpy que se comporta como a versão anterior da memcpy da glibc. E roda usa o LD_PRELOAD pra que todas as chamadas à memcpy sejam ligadas com a memcpy dele.
Que bagunça: os caras mudam a biblioteca, os desenvolvedores que usam a biblioteca não seguem a mudança, a solução é recompilar códigos em C com se isso fosse trivial.
O coitado que só quer assistir Walking Dead ou ver os gols do domingo é que se dá mal. Pois não sabe nem o que é compilar.
Vemos ai um grande exemplo de várias coisas que nunca devem ser feitas. Isso é, se você quiser ter sucesso comercial com software.
Linus atira no olho pra não estragar o couro! Ele ta sempre fazendo isso, igual quando acordou de cueca virada e puto com os sistemas de versão de controles existentes e resolveu criar o git, taê que virou!!
Isto é muito ruim mesmo sabendo que quem não quisesse poderia evitar a atualização o fato é que o desenvolvedor criou uma incompatibilidade com base no principio simplista de que era melhor do jeito que ele pensou. Isto é um dos pecados do software livre pois tem muitos desenvolvedores que acham que podem abandonar o legado por conta 1% a mais de performace e acabam perdendo 10% dos seus usuários afinal manter e ampliar a base de usuários é mais importante para a vida do projeto do que manter e ampliar a performace.
Lamentável, tudo por causa de um ego inflamado.
Bom, pelo que eu vi, isso era um recurso que não devia ser usado como dizia explicitamente a documentação, além de ser um problema pelo fato de não ser assim que ela devia funcionar.
Bom, arriscaram e deu nisso. Acho que apenas faltou tato para como corrigir, mas nesse caso realmente não vejo outra forma da parte da glibc.
Por essas e outras que se entende as discussões no Debian acerca do uso da elibc: glibc, no way, pessoal tá sempre com essas picuinhas :S
Hehe
“remendo torvaldiano” eu ri.
Agora é sério @Fernando Miranda tem razão a correção deveria partir do desenvolvedores não do usuários, já que parte não são desenvolvedores (acho que esses já são em maior número que o outro se não forem torço muito pra que sejam ).
Sinceramente acredito que existe um pouco de orgulho do desenvolvedor da glibc de não tentar uma solução politica para o assunto, mas os desenvolvedores que fizeram uso da instrução mesmo tendo declaração explicita para não faze-lô não tem muito do que reclamar.
Se é isso mesmo, o desenvolvedor da glibc só errou em ter deixado a coisa funcionar fora do padrão por algum tempo.
Uma alternativa que poderia ter sido tomada, baseado em outros projetos:
Comunicar previamente nos forums da Glibc que o comportamento X irá mudar a partir do release Y, previsto pra alguns meses.
Assim, todo mundo teria tempo pra tratar seus programas ou mitigar os riscos, já que a Glibc é a espinha dorsal da maioria dos softwares Linux, e mesmo que seja um recurso pouco usado e não incentivado, o risco de ter impacto é menor.
Lembrei das registers globals do PHP.
E se esse problema tivesse ocorrido no debian ou gentoo, será que o Linus teria essa mesma preocupação que teve com o fedora ?
Respondendo: Não o Linus não teria preocupação, pois o mesmo usa Fedora e não Debian ou Gentoo. Ou saberia se ocorresse no Fedora também.
Já colocado antes o Linus usa Fedora e não Debian ou Gentoo, mas claro é necessário fala mal de alguém que vai e faz as coisas.
Típico de brasileiros.
Na minha opinião ele inerviu porque aconteceu dele ver a lista de bugs e tal. Duvido que acnteceria se fosse por acaso uma distro com uma comunidade ainda mais restrita como o openSUSE, Madriva, Gentoo etc…
Mais uma vez fica aquela duvida em dar uma atualizada no sistema e de repente acontece de alguma coisa “quebrar”. Não é a primeira vez que acontece isso e há casos que até hoje não se resolveram, como o caso do driver legacy da nvidia 96xx que ainda não tem suporte no xorg 1.9, pelo menos não funciona no Arch Linux.
Um comentário lá:
“Out of the thousands of commonly used packages, almost all have always had some user on a platform that doesn’t handle overlapping ranges to memcpy. Flash is essentially the last to get hit by the change: everybody else hit the issue earlier on platforms that don’t get much press.”
se o flash fosse open source, a mudança na glibc não seria essa ‘catastrofe’..
E não foi apenas o som que apresentou problemas. A duas semanas atrás meu VirtualBox deixou de funcionar. Pensei que a causa fosse algo que tivesse feito- alguma atualização do VB com bug. Instalei versões anteriores,mas não resolveu. Nos fóruns, descobri que foi uma atualização da glib que causou o problema. Apesar da falha já ter sido reportada, nenhuma resposta foi dada…
A solução de contorno que surgiu foi a execução da VB como root e importação das VM’s.
Ocasionalmente tb uso fedora. Achei a resposta num forum desta distro e não sei se outras distros foram afetadas.
Se eu estiver esquecendo algum ponto importante, por favor me digam, mas vejo da seguinte forma…
Softwares mudam constantemente (por performace, bug fix ou features), isso é normal. Mas o que causou essa confusão foi o fato da distro ter incorporado a nova versão da glibc sem antes fazer os testes necessários (e imagino que no caso da glibc sejam muitos testes).
Concordo com o comentario do @Tom. Cade o pessoal da homologação??? Isso passou despercebido pelo pessoal do Fedora??? Incrivel!!… E não vale dizer que isso podia (pode) ter acontecido com Debian, Gentoo, Slackware ou Ubuntu… Alias eu uso este último e atualizo ele direto e não tive problemas com a glibc. Será que a Canonica foi mais rápida e corrigiu o problema?. Sei lá, não to querendo colocar flame (mas já o fazendo :>) ), nas o Fedora tem um pessoal que homologa as coisas não tem???
Corrigindo dois erros:
Onde se lê “Canonica”, leia-se Canonical.
Onde se lê “nas”, leia-se mas.
Valeu
O Debian está para adotar o LZMA nos pacotes há anos. O dpkg tem suporte a LZMA desde o Etch. Assim, quando for feita a mudança o impacto será muito próximo de zero.
Quando a pessoa tem domínio do negócio fica fácil compilar meia duzia de código, mas os simples mortais como eu temos que aguardam as atualizações.
Já não é de hoje que algumas atualizações do glibc matam o VMWare Server 2.0.2 64 bits (em CentOS), faz uns 4 dias que também está se comportando estranho. Máquina virtual morre do nada. Forçando uma versão mais antiga funciona perfeitamente…
Quero ver quando o register_globals do PHP morrer (previsto pro PHP 6). Absurdo é gente que ainda usa isso… não é o caso aqui, mas o fato é que se estava documentado, todos que usam já deveriam ter modificado. Lembrando claro que um teste básico da distribuição poderia ter evitado todo esse murmúrio…