Sendo bom para todos, viva a evolução!
Eu não sei ao certo, mas tenho a impressão que isso vai feder um pouco! =/
Терпение быстрее лопается у тех, кого надули.
Н.ВЛАДИМИРОВ.
A EGLIBC é uma licença tão livre como a GLIBC, elas tem uma licença idêntica e seguem a mesma ideologia. Possui compatibilidade com programas GLIBC. Estou curioso em relação à comparação de desempenho entre as duas, mas como a EGLIBC foi feita pensando em sistemas embarcados, suspeito que ela seja mais rápida. E o fato de não ser mantida por Ulrich Drepper é algo positivo.
Pessoalmente, acho a mudança algo positivo. Pode ser que surjam alguns eventuais problemas, mas acho que isso será muito bom à longo prazo.
O pessoal do Haiku esta fazendo uma reimplementação focada em Desktop, o primeiro patch tinha 12 MB, diminuiu o boot de 25 segundos para 12 segundos. O desenvolvedor está fazendo o port do Chrome teve que modificar algumas coisas e a coisa acabou ficando grande no editor.
Antes que o pessoal comece a xingar o Uli Drepper, melhor olhar outros sites que publicaram a mesma notícia ( em especial em inglês, como a do tuxradar ) e ver os comentários a favor do Uli. Quanto a implementação da EGLIBC, seria óbvio que eles não iriam mudar só por causa de uma discussão e de um cara “marrento” como mantenedor ( se bem que o próprio já é bem famoso por conta disso hehe ).
Quando se é informado de bug o certo a fazer é arrumar o código e não responder “‘for the sole benefit of this embedded crap”.
me ajudem na minha falta de conhecimento, a GLIBC não é a responsável por ter os fontes das chamadas de sistema?
pessoal, o GLIBC não é responsavel por ter os fontes das chamadas de sistemas?
Graças a Ulrich Drepper, a glibc está no passado. Até hoje não tem implementações de strlcpy e strlcat, uma das coisas mais básicas que se esperaria de uma libc moderna…
Amén ao projeto Debian! Finalmente alguma distribuidora de Linux decidiu progredir…
Acho que o único problema (que não é pequeno) vai ser da compatibilidade de pacotes e dependencias. Mais uma vez um pacote que funciona em uma distribuição não vai ser compatível com o de outra.
Mas se essa versão for melhor, é torcer pra que se torne a padrão.
@kayo, Não entendi a pergunta.
@*, Sou a favor da mudança de libc, apesar de não conhecer a eglibc. Mas já vi sistemas com a uclibc, por exemplo, e são realmente superiores e mais leves.
Como diria o outro: GNU é o cara**o!
O Stallman quase deve ter tido um infarto quando leu isso…
Já vi esse filme antes. Aconteceu com o GCC e o EGCS. Depois o EGCS virou ou o GCC “oficial”.
Só para complementar, aposto que o próximo é o EMACS.
Eu gostaria que o EMACS sumisse e o VIM virasse oficial. Seria muito bom, porque nem todo mundo tem quatro braços para digitar CRTL-X CRTL-F.
@marcosalex,
A glibc já não era compatível com ela mesma! – a cada nova versão, geravam-se incompatibilidades nos binários – fato que eu jamais consegui compreender, pois demonstra um desinteresse, quase desleixo, em padronização da ABI.
Um componente tão importante e básico como o libc não pode ficar mudando sua ABI todo dia. A falta de compromisso com a retrocompatibilidade no glibc, na minha opinião, é um dos maiores problemas para a compatibilidade binária entre as diversas distros.
Espero que a eglibc tome mais cuidado com isso.
Na verdade a tendência é que compatibilidade melhore.
Vale lembrar que todas as principais distribuidoras de Linux distribuem versões muito modificadas da glibc, pois a versão “oficial” em geral não está pronta para o “vamos ver”.
Então usar a eglibc pode provavelmente levar a uma maior unificação e acabar com os conjuntos de modificações diferentes e o trabalho duplicado das distribuições, a exemplo do que aconteceu com o XFree86 e o GCC (que viraram respectivamente X.org e EGCS, este sendo depois oficializado).
A julgar pelos relatórios de bug que constam na notícia e o suporte recentemente adicionado à glibc ao uso de, pasmem, XML (!) para armazenar estatísticas de alocação de memória, o sr. Drepper é totalmente incompetente. Eu recomendo que vocês dêem uma olhada direto no código-fonte da glibc, no arquivo malloc/malloc.c, mais especificamente na função malloc_info. Preparem-se para se deparar com código muito amador…
A glibc também tem se tornado cada vez mais ligada ao Linux, ficando muito difícil de portar.
A glibc já não era compatível com ela mesma! – a cada nova versão, geravam-se incompatibilidades nos binários – fato que eu jamais consegui compreender, pois demonstra um desinteresse, quase desleixo, em padronização da ABI.
Hã? A ABI da glibc não muda há muito tempo (ou pelo eu não percebi nada), não sei do que você está falando…
De qualquer modo, se você quer compatibilidade binária, é porque você não tem o código-fonte (i.e. software proprietário), e se o seu software é proprietário então você vai querer ligá-lo às bibliotecas estaticamente mesmo…
@Jack Ripoff
Sobre a opiniao do Drepper a respeito dessas funcoes, vide:
http://sources.redhat.com/ml/libc-alpha/2000-08/msg00052.html
@Jack Ripoff
De qualquer modo, se você quer compatibilidade binária, é porque você não tem o código-fonte (i.e. software proprietário), e se o seu software é proprietário então você vai querer ligá-lo às bibliotecas estaticamente mesmo…
Errado. Se eu quero compatibilidade binária, é porque eu não quero recompilar cada peça de software que pretendo usar. Ainda que o código-fonte esteja disponível, eu quero baixar o “arquivo executável”, instalar, e pronto.
Atualmente, cada distribuição tem que recriar todos os seus pacotes para cada uma de suas versões. Um pacote criado para o Ubuntu 8.10 não vai rodar no Ubuntu 9.04.
Não consigo entender: por que aplicativos binários do windows 3.11 continuam rodando no windows xp, e as distribuições Linux não conseguem manter a compatibilidade binária nem entre duas versões consecutivas???
Será que a MS é mais competente que os desenvolvedores de SL?
Mas já disseram mil vezes que tem compatibilidade binária!
Errado. Se eu quero compatibilidade binária, é porque eu não quero recompilar cada peça de software que pretendo usar. Ainda que o código-fonte esteja disponível, eu quero baixar o “arquivo executável”, instalar, e pronto.
Você deveria usar Windows então. Não é assim que Unix funciona. Unix usa compartilhamento de código e abomina essa idéia “Microsoftiana” da “retro-compatibilidade ad nauseam” – afinal as coisas precisam evoluir, até a Apple finalmente abandonou a retro-compatibilidade com os sistemas de legado…
De qualquer modo, o Unix é tão flexível que ele até pode funcionar desse jeito que você quer. Vide o PC-BSD. É só fazer o que eu falei: ligar tudo estaticamente!
Não consigo entender: por que aplicativos binários do windows 3.11 continuam rodando no windows xp, e as distribuições Linux não conseguem manter a compatibilidade binária nem entre duas versões consecutivas???
Pelo mesmo motivo que o Windows XP ainda sofre de bugs de mais dez anos atrás e ainda sofre com proteção de memória imperfeita.
Somente um retard4do nos dias de hoje iria querer retrocompatibilidade. Se o preço para a retrocompatibilidade for ficar igual ao windows, aka bugado, imperfeito_demais e inseguro, então, não quero.
O preço para a sobrevivencia do gnu/linux eh justamente este, da anta paralítica ter que pegar versoes especificas ou recompilar para um sistema especifico.
@Henry Ford,
os automóveis evoluíram muito: os carburadores foram substituídos pela injeção eletrônica, o distribuidor e platinado pela ignição eletrônica, os freios ganharam controle ABS, o escapamento ganhou catalizador…
os MECÂNICOS, TÉCNICOS e ENGENHEIROS automotivos tiveram que se adaptar a todos esses novos conhecimentos, mas para o MOTORISTA, nada mudou. Tanto faz se o seu carro usa tecnologia A ou B, você o dirige exatamente da mesma forma.
citando suas próprias palavras, somente um retard4do pode defender que cada usuário (que você chama de anta paralítica) deva recompilar tudo, ou depender de pacotes específicos.
essa atitude arrogante de nerd que se acha um deus supremo, acima dos meros mortais, é que dificulta a adoção de SL em larga escala.