| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | na minha modesta e inculta opinião devo dizer que não tenho uma boa impressão de como o desenvolvimento do kernel de linux é feito. já tive vários problemas de alguns drivers e depois venho a descobrir patches nalgum canto obscuro da net ou mesmo um outro driver desenvolvido por outro hacker - e sem qualquer referência na source que vem no kernel!? Dou exemplos de algum HW bastante comum da NSC e da Intel. Parece-me DEMASIADO desorganizado... Em relação a este problema específico, alguém conseguiu compilar o 2.4.12 ? tive que aplicar patches para o 13pre-1 e os restantes pre não funcionam.
|
| | | | | | | depois venho a descobrir patches nalgum canto obscuro da net ou mesmo um outro driver desenvolvido por outro hacker - e sem qualquer referência na source que vem no kernel!? E acharias lógica ter no kernel referência a um patch que corrigisse o kernel? O mais certo é que na altura ainda fosse desconhecido o patch, a pessoa que o fez não o tenha submetido, ou devido a outras prioridades o patch ainda não tenha sido incorporado. Relativamente ao kernel 2.4.x, aconselho as pessoas a manterem-se pelos -acxx, que se têm mostrado mais estáveis e já trazem o suporte para ext3. Já saiu o 12-ac3. Mas se não quiseres aplicá-lo tens o patch que te corrige o typo no driver da porta paralela linux-booboo.patch, juntamente com outros patches. Anyway, é o preço a pagar por andar na borda do precipício... Estou ansioso para que comece a linh 2.5 para o 2.4 estabilizar...
hugs
Strange |
| | | | dá uma vista de olhos no driver da placa de rede Intel Express Pro 100...eu tive problemas com o driver que vem no 2.4.x e mais tarde, sem qualquer referência no driver que lá vem, apenas por pesquisa na net, venho a descobrir que existe um driver próprio da intel e que funciona BEM. se consultares o cabeçalho do eepro100.c vês lá:
2000 Jul 17 Goutham Rao
e o driver que estou a usar é deste ano... dou outros exemplos se quiseres... PS: estou a usar o 2.4.13-pre1
|
| | | | | 2000 Jul?? Isso e' antes do proprio 2.4.0! Mas ja' vi e esta' la' isso mesmo... Mas falando do driver para a tua placa (driver v1.6.22, não?), nota que: "The Intel PRO/100 Driver is only supported as a loadable module at this time. Intel is not supplying patches against the kernel source to allow for static linking of the driver." E nota também que a licença não é GPL. Se fizeres um cat /proc/sys/kernel/tainted, verás (ou deverias) que o teu kernel está infectado, podre, putrefacto. :) De qualquer modo, isso não anula o que eu disse: não faria sentido vir no driver do kernel um link para um outro driver ainda inexistente; e a Intel pode não o ter submetido ou oferecido para inclusão no kernel...
hugs
Strange |
| | | hehehe (Pontos:3, Informativo) |
| | A culpa disto é do Linus.
Ainda não percebi porque é que tem de sair um kernel novo todas as semanas, e ainda percebo menos porque é que há muitas pessoas que tem de ter sempre o ultimo kernel instalado e quando não é a versão alpha.
Gosto muito mais do modelo do FreeBSD em que só lança x.1 e não 2.x.xx ou seja lança um novo kernel cada três meses ou quatro e não todas as semanas. Quanto as correcções ou bugs existem patches e o CVSup as novas features só são lançadas depois de algum tempo de teste ( no openBSD passado muito tempo mesmo), é esta filosofia que torna o *BSD mais estavel do que o Linux.
Sem falar por exemplo de outros Unix's comerciais como o Solaris que lança maitenance updates ( o Solaris 8 já vai no quinto ).
Não só torna os SO's mais estaveis mas tambem ajuda no software proprietario que muitas vezes só está certificado para kerneis muito mais antigos do que o actual.
|
| | | | | | (...)Sem falar por exemplo de outros Unix's comerciais como o Solaris que lança maitenance updates ( o Solaris 8 já vai no quinto ).(...)
Quando se fala de unixes comerciais não nos podemos esquecer que correm numa variedade muito menor de hardware (e em plataformas não x86 ainda menor), logo, quase não sofrem dos problemas causados por hardware estranho e infinitas combinações que os programadores obviamente não podem testar.
-- Carlos Rodrigues
- "I think we can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | Poix..... agora ja sei o que me aconteceu.. TOO LATE :( DAMN
Perdi mais de 30 GB em dados, advinhem ... 2.4.X :(
Quase mandava o disco para troca a pensar que fosse falha de hardware o que se veio mais tarde a comprovar que não correspondia a verdade. Visto o mesmo hardware estar a trabalhar a 100% agora.
Sim pois fui um dos azarados que teve o dessabor de comprovar que o mesmo era verdade. Devo ter uma queda para esse tipo de coisas. Cheguei a culpar o tipo de fs que usava ja dizia mal ate dizer que chega do mesmo (reiserfs) inclusive levou me a passar a usar xfs.
Acho que ao ritmo que estão a ser lançados as versões, não deve realmente haver muito tempo para se verificar bem as coisas, acho que eles ganhariam mais em lançar menos versões ditas "finais" e aperfeiçoarem mais as que existem e não andarem numa correria desatada sem mais nem menos. Daqui a uns tempos isso ainda vira Microsoft a lançar os produtos para os terminar nas instalações dos clientes é da pior maneira.
O meu centimo.
|
| | | | Para responder a alguns dos posts acima de uma rajada só deixem-me dizer-vos algumas coisas: O kernel do Linux tem uma evolução aparentemente desorganizada porque é muito mais aberto a contribuições e muito mais mediatizado do que outros clubes mais elitistas (*BSD) mas isso não corresponde inteiramente à verdade, mas passemos ao próximo ponto...
Para todos aqueles que insistem em correr sempre o último kernel do Linus deixem-me informár-vos de que o kernel do Linus não deve ser interpretado como The One True Way(tm) mas sim como uma referência comum e como um modo de direccionar o seu desenvolvimento, (lembro-me de uma discussão qualquer na lkml acerca disto) deixando portanto aos distribuidores a tarefa de o customizar à sua medida. "Mas que estupidez!" pensam vocês, pois, seria bom que houvessem duas versões constantes do Linux, uma em desenvolvimento e outra estável, não muito longe uma da outra (à lá *BSD). Isto aceleraria o passo do desenvolvimento de maior parte do kernel (principalmente a inclusão e manutenção de alguns drivers), mas tornaria mais difícil revolucionar alguns dos seus subsistemas (o que normalmente acontece sempre nas versões ímpares do Linux). Mas continuando... esta forma escolhida pelo Linus permite manter o código da tree principal mais ou menos limpo de hacks, nada entra sem a aprovação do mestre e todas as soluções têm de ser o mais elegantes possível, aqui entram os distribuidores que incluem nas suas versões esses mesmos hacks (que funcionam) até algo de melhor aparecer. Eis então a razão de alguns drivers nem sequer compilarem durante sucessivas versões do kernel sem a aplicação de alguns patches feios.
Conclusão: o Linux tem sempre duas versões de desenvolvimento, uma que realmente é terreno pantanoso (ímpar) e outra que é quase quase estável (par), as realmente estáveis e que passam por testes de stress são as das distribuições.
O Linux é uma comunidade, pensem nisso ao mesmo tempo que pensam sobre o porquê das versões do Linux para diferentes plataformas serem desenvolvidas em árvores separadas ("For platform <foo> get the platform specific tree"). As distribuições são o ponto unificador e é nisso que o Linux é diferente de outros free *nixes onde apenas existe uma distribuição (se isto é melhor ou pior depende do gosto de cada um).
Parece confuso e é, não é lá muito bonito... concordo, mas não é assim tão mau como dizem e além disso se os distribuidores tiverem cabecinha e não forem demasiado aventureiros é até uma boa política (eu pelo menos nunca tive problemas de maior).
-- Carlos Rodrigues
- "I think we can handle one little penguin!"
- "No, Mr. Gates, your men are already dead!"
|
| | | | Das duas uma:
-Ou voces (que usam ou usaram o 2.4.11/12) nao seguem o desenvolvimento do kernel
-Ou seguem mas gostam de andar perto do abismo e sabem que podem cair de vez em quando (se nao sabem, deveriam saber 8)
para quem nao segue, o linus esta divertido a usar o 2.4 como mesa de testes, a fazer/aceitar grandes mudancas num kernel que deveria estar apenas a limpar problemas... ou seja, o 2.4 neste momento para o linus e' o 2.5
o alan por exemplo ainda nao mudou para a nova VM por a achar demasiado perigosa para um kernel 2.4
e diz que ainda vai demorar mais uns 4 kernels ate' ela ficar limpa de bugs e fiavel
ou seja, usar um kernel do linus mal ele sai e' como usar um 2.5, um pouco como jogar a roleta russa, quase de certeza que corre bem, mas pode correr mal (e como agora, muito mal)
neste momento, se nao se tem razoes para mudar de kernel, nao se deve mudar.
se se quer mesmo mudar, esperar uns tempos e ir seguindo a lkml para ver se nao existem problemas graves e se assim for, podem usar esse kernel
o problema e' a politica que veio do windows de usar sempre a ultima versao, quem a usa corre estes riscos, e na maior parte das vezes inutilmente, pois a anterior funcionava bem e/ou apenas se corrigiu bug de outras sistemas ou de driver que nao teem...
e' apenas uma questao de dizer que se esta' a correr as ultimas versoes de tudo
a velha maxima continua aplicavel:
If it isnt broke, don't fix it
Higuita |
| | | | quem te mandou a ti comprar um Athlon a 1.xGHz? É tão rápido que o kernel nem tem tempo para pensar ;)
|
| |
|
