Barrapunto

main(){malloc(10000);fork();main();}

o algo así.

Si a él le aburren, ¿por qué no se dedica exclusivamente a la rama inestable?, es decir, ahora q ha comenzado la 2.5, q siga en ella y Marcelo en la 2.4 y, cuando decida que la 2.5 está terminada, que salga la 2.6 pero que de esta rama se encargue otra persona (Marcelo, por ejemplo) y él que abriese la 2.7.

Sé que esto suena raro, pero al menos él no se aburriría y no sacaría versiones inestables en la rama (supuestamente) estable.

Me revienta la gente que habla como tú. ¿Acaso los desarrolladores del kernel te deben algo?.

Instalarse la última versión del kernel es _opcional_. Que sale un kernel que tiene fallos...pues bueno..corriste el riesgo y fallaste. ¿A quién le exiges que el kernel sea estable?.

El problema no está en los desarrolladores, sino en la _poca_ gente que testea los kernels. Ese es el problema. Poca gente prueba ya los pre, y ese es el motivo por lo que se han producido tantos fallos, junto con una mala implementación de la MV desde el principio.

Colaboremos un poco más y quejémonos un poco menos. Siempre puedes usar Windoze, y quejarte después por algo que has pagado.

¿Qué tal algo así? :

#include stdio.h
#include stdlib.h

main(int argc, char** argv){
    /* Primer argumento numero nuemro de megas a reservar, segundo
      tiempo de siesta*/
    void *p;
    unsigned long nmegas, nseconds, h;

    p = calloc(nmegas, 1024*1024);
    sleep(nseconds);
    free(p);

}

Que es más o menos lo que viene en
http://www.byte.com/documents/s=1436/byt20011024s0 002/1029_moshe.html
     

... que se presten a ese juego ;). Por eso y porque empezar una en desarrollo sin tener una estable (de verdad) detrás no es un buen comienzo.

Lo dice aqui
el propio Linus.

O al menos eso entiendo yo.
 

Faltan las asignaciones ;):

nmegas = atoi(argv[1]);
nseconds = atoi(argv[2]);

No me hagas mucho caso pero puede que el programa recursivo anterior en este hilo desbordara la pila y por eso no funcionaba.

Si se aburre, que construya mas aplicaciones, ya que solo ampliando linux es para cometer mas errores.

Del kernel no depende porque a mi me funcionan los dos programas(el recursivo, por cierto, me funde pero bien). Igual es algo de los límites del usuario (de procesos y de memoria)...

 

main() { for(;;) fork(); } y con eso hace un exploit que el OOM Killer no te puede hacer ná.

Aquí no se exije que el kernel sea tal o cual.
Pero si se dice: Hola soy linus y empiezo la rama 2.4 porque ya es estable, y luego resulta que empieza a haber cagadas por todas partes...pues no es serio, pero nada serio. Y si, no hemos pagado nada, pero no por eso nos vamos a callar lo mal que esté. Y cambiar la VM en medio de una serie estable..pues sinceramente no me parece serio, meter los nuevos sistemas journaling en medio de una serie estable, pues no me parece serio...y un largo etc...
Y no me saltes con eso de que pues no lo uses. Pues claro que lo uso, pero también quiero que sea estable. No exijo, pero no por eso nos vamos a callar.

Que raro, yo en mi woody/sid con kernel 2.4.13 empiezo a abrir aplicaciones a lo bestia y cuando me va a rebosar la memoria total siempre me mata la aplicación más grande en ese momento: StarOffice o Mozilla, y no se cuelga en absoluto.

Linus es uno de los mrejores programadores que tiene el kernel, si no el mejor. La razon es que le aburre estar manteniendo un rama estable, en la que se supone que lo unico que se hacen es corregir errores. Y por eso a veces saca versiones demasiado pronto (segun sus propias palabras en la lkml). Lo que a el le gusta es desarrollar, probar, arreglar cosas, y ese tipo de cosas que solo se hacen en las ramas inestables. Y el hecho de que sea la rama inestable, no quiere decir que solo se hagan cosas chapuzas para arreglarlas despues en la estable. La rama inestable es donde se arreglan la mayor parte de los problemas, en la estable se corrigen por lo general problemas menores.
De hecho, el bug del 2.4.15 es logico, pensando que es exactamente lo mismo que la version de desarrollo. Solo deberia haber salido en la version inestable, lo hubieran corregido y no habria pasado a mas.

La razon no es que no le quepa en la cabeza. Es simplemente, que como a muchos otros desarrolladores, lo que le gusta es estar en la rama de desarrollo. Lo cual quiere decir que si Linus no fuera tan impaciente (se le veian ya las ganas de la 2.5.X) pues hubiera sido una version estable, como hubiese querido Alan Cox: Sin ningun cambio de VM ni nada raro, y se hubiera alcanzado la 2.5 por la version 2.4.8 o asi.

Lo que quiero decir es que lo que hace falta es un manutentor(se dice asi??) de un serie estable que sepa llevarla bien estable. Un ejemplo muy bueno es el de Alan Cox, que lleva la rama 2.2 muy bien. A mi personalmetne me hubiera gustado que Alan hubiera llevado la 2.4.X...pero no se le puede obligar.
Lo que quiero decir es que no creo que linux sea demasiado grande para un persona, sino que hace falta una persona adecuada para mantener lo kernels estables. Y el mismo linux esta dando a entender (y ha demostrado) que el no es la mejor opcion. Ahora, si quiere seguir haciendolo, yo no soy nadie ni aqui ni en la lkml para mandarle.

Y el 2.5.1-pre2 tambien....

Cambiar la VM no me parece demasiado bien pero los nuevos sistemas de journaling son necesarios y si están bien probados que los meta. En las versiones estables también se meten nuevos controladores de dispositivos y no por ello dejan de ser estables.
Claro que el sistema de ficheros y la gestión de memoria es algo serio pero si se prueba el código exahustivamente antes no debería haber ningún problema.
Por mucho que sean versiones estables no quiere decir que sólo se arreglen bugs y no mejoren desde la 2.4.0

Leete los post's de antes y sabrás porque hablé así... eso de criticar a alguien sin ni siquiera saber a que venía mi post está fuera de lugar criatura :)

    Venía a que la solución decían que era "ponte uno estable" y te guste o no 2.4 está declarado como estable, y eso no lo he dicho yo... lo ha dicho un tio mu'famoso que se encarga del kernel... metete con el :)

Un abrazo :)

> Claro que el sistema de ficheros y la gestión de memoria es algo serio pero si se prueba el código exahustivamente antes no debería haber ningún problema.

No debería,jejeje. Pero yo me ciño a lo que esta pasando, no a lo que "debería" estar pasando

Está claro que es porque no los han probado exhaustivamente. ¿Estamos heredando los vicios de windows?