Barrapunto

• Detener todos los procesos como syslog, cron, mysql ,etc
• Hacer un sync
• Apagar y prender la máquina directo con el interruptor

Esto fué hecho en 2 PC con Debian Woody a las que había instalado el 2.4.15 y no hubo ninguna "corrupcion" que lamentar (probado después con fsck). Una máquina tiene la particion raiz como reiserfs y la otra ext3.

Vi también la recomendación de hacer un shutdown -F (Force fsck on reboot). ¿Alguien ha tenido problemas con un shutdown normal?

Simplemenete decir que he comprobado el sistema de ficheros varias veces desde que se anunció el problema de corrupción del sistema de ficheros y no he tenido ningún problema.

Cierto es que he actualizado enseguida al nuevo kernel, por si las moscas ;-D.

Yo después de detener todos los procesos que pude (todos los que no eran imprescindibles) hice un sync y un reboot, sin más, y no me pasó absolutamente nada malo, ni fuera de lo normal.

Después volví al 2.4.14, pero desde ayer tengo el 2.4.16-pre1, y va perfectamente. Como las diferencias con el 2.4.16 son mínimas, creo que esperaré que salga el 2.4.17 ;-)
 

Lo de windoze es más triste, pasan meses/años entre parches/versiones sucesivos y siempre va de pena.

Que tiene guasa, por lo menos si sacaran algo estable de vez en cuando... X'-DDD

Bajar el linux-2.4.16.tar.bz2 (o .tar.gz), copiarlo a /usr/src, descomprimirlo, etc ..

Con los parches (patch) puedes pasar de una version a otra (por ejemplo el patch-2.4.13 te sirve para tener el código fuente del 2.4.13 a partir del 2.4.12)

Si ya tienes el linux-2.4.12.tar.bz2 solo necesitaras los siguientes parches (los puedes bajar de aqui):

• patch-2.4.13.bz2
• patch-2.4.14.bz2
• patch-2.4.15.bz2
• patch-2.4.16.bz2

Vas aplicando cada parche en secuencia hasta llegar al kernel deseado (2.4.16 en este caso)
bzip2 -dc patch-2.4.13.bz2 | patch -p0
bzip2 -dc patch-2.4.14.bz2 | patch -p0
bzip2 -dc patch-2.4.15.bz2 | patch -p0
bzip2 -dc patch-2.4.16.bz2 | patch -p0

Y listo, ya lo puedes compilar

También, pero no sólo eso. Lo ha dicho el propio Linus en este correo que resulta altamente explicativo por sí mismo. No le gusta mantener código, y como resulta que se "aburre" haciéndolo, saca las versiones tan pronto se harta de ello (que suele ser demasiado pronto). Con Marcelo Tosatti al cargo, en labores de mantenimiento puro, podemos esperar pocas sorpresas más en la serie 2.4.x.

Por cierto, y sin que sirva de excusa, los usuarios "normales" no suelen meterse a compilar núcleos alegremente. Los que lo hacen normalmente saben (o deberían a partir de ahora) saber que si bien se suponen estables, no son código que hayan pasado un proceso de verificación de calidad que se pueda considerar mínimamente aceptable. Para los usuarios de vida tranquila, núcleo de la distribución y preguntar a los que sepan más :)
 

En Linux la mierda no sólo se ve, sino que se airea y se discute para saber cómo evitarla en lo sucesivo. Muchas veces en software propietario, la mierda no sólo se oculta sino que suele meterse en una caja de colorines envuelta en papel celofán, y se vende a precios nada despreciables.
 

Como ya comenté en esta historia, el parche que finalmente formó parte de las -pre1 y de 2.4.16 se encontraba disponible exactamente 1 hora después de notificado por primera vez el problema.
   

Y en cuanto a lo de los usuarios normales tienes muchísima razón, pero el problema es que el hardware avanza que es una barbaridad y pienso que el principal motivo por el que la gente se instala núcleos exóticos es para dar soporte a su flamante nuevo escáner USB, su tarjeta de sonido... etc, por eso siempre habrá gente que se juegue la vida instalando la ultimísima versión...

El problema está en las excesivas prisas para sacar versiones, bajo mi punto de vista... O que, básicamente, 2.4 aún no estaba preparado para venir al mundo (tenían que haber seguido unos cuantos meses más con 2.3)

No es exactamente "colgado", sino claramente "inusable". Pero este ha sido un comportamiento de Linux toda la vida: funciona muy bien a menos que entre en trashing. ¿Alguna pista de cómo evitar que a partir de X swap ocupada un proceso no siga ocupando memoria?

Apliqué el patch de Andrea Arcangeli y ahora no tengo nada de problemas. Sigo esperando un día o tres antes de instalar 2.4.16.

He activado ext3, y funciona bien; cuando mi computadora acabó de funcionar, y tuve que empujar "reset", ext3 no tuvo problemas y no hizo un fsck.

  Si yo estoy teniendo estos problemas, que se qué es el kernel, a un recién llegado a Linux sin conocimientos informáticos le va a causar una impresión muy pobre la calidad del software libre por los problemas del kernel.

  Está ocurriendo lo que Eric Raymond predijo hace un año y medio, y hubo intentos de linchamiento en slashdot por ello -y eso que era Eric, si llega a ser un Juan Nadie...-. A ver si paramos de una vez con el "star-system", y comenzamos a escuchar cosas como "baterias de pruebas" o "pruebas regresivas". Por eso me anima el proyecto janitor, que sí creo que va en la dirección correcta.