Rael (usuário não registrado) em 11/11/2010 às 9:08 am

Isso lembra um pouco toda aquela discussão do ext4. Ainda bem que desta vez o Linus interveio.

CArlos (usuário não registrado) em 11/11/2010 às 9:20 am

Provavelmente ele utiliza o Fedora, é bom isso.

Cristiano Ricardo Peixoto Pena (usuário não registrado) em 11/11/2010 às 9:23 am

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.

Renato (usuário não registrado) em 11/11/2010 às 9:23 am

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.

Fernando Miranda (usuário não registrado) em 11/11/2010 às 9:26 am

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.

franklin anderson de oliveira souza (usuário não registrado) em 11/11/2010 às 9:39 am

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!!

santo em 11/11/2010 às 9:51 am

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.

Renyer (usuário não registrado) em 11/11/2010 às 9:53 am

Lamentável, tudo por causa de um ego inflamado.

Psycho Mantys em 11/11/2010 às 9:54 am

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.

arthas_dk (usuário não registrado) em 11/11/2010 às 10:26 am

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

Junin (usuário não registrado) em 11/11/2010 às 11:25 am

“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 ).

Víctor (usuário não registrado) em 11/11/2010 às 11:44 am

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.

Igor Ramos Tiburcio (usuário não registrado) em 11/11/2010 às 12:54 pm

Se é isso mesmo, o desenvolvedor da glibc só errou em ter deixado a coisa funcionar fora do padrão por algum tempo.

Marcos (usuário não registrado) em 11/11/2010 às 3:08 pm

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.

Mário RPG (usuário não registrado) em 11/11/2010 às 3:26 pm

E se esse problema tivesse ocorrido no debian ou gentoo, será que o Linus teria essa mesma preocupação que teve com o fedora ?

Covarde Anonimo (usuário não registrado) em 11/11/2010 às 4:37 pm

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.

Onife (usuário não registrado) em 11/11/2010 às 4:45 pm

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.

elias (usuário não registrado) em 11/11/2010 às 5:41 pm

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’..

andreluiz_net em 12/11/2010 às 2:04 am

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.

Tom (usuário não registrado) em 15/11/2010 às 3:23 am

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).

Gilberto Nunes (usuário não registrado) em 15/11/2010 às 11:50 am

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???

Gilberto Nunes (usuário não registrado) em 15/11/2010 às 12:08 pm

Corrigindo dois erros:

Onde se lê “Canonica”, leia-se Canonical.
Onde se lê “nas”, leia-se mas.

Valeu

Marco (usuário não registrado) em 15/11/2010 às 12:34 pm

Comunicar previamente nos forums da Glibc que o comportamento X irá mudar a partir do release Y, previsto pra alguns meses.

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.

Ronaldo (usuário não registrado) em 15/11/2010 às 8:00 pm

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.

gicapp (usuário não registrado) em 15/11/2010 às 10:59 pm

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…