Nada es bueno si no es interesante. El parche de ~ 200 líneas "milagro" promete una gran mejora en la capacidad de respuesta de escritorio, pero Lennart Poettering (de Red Hat) ha respondido a los comentarios de Linus con 4 líneas de bash que llevan a cabo la misma función, en el actual 'vanilla kernel'.
#8:
Desde luego, cada thread que leo de Torvalds más estúpido me parece. Habrá hecho mucho por el mundo de la informática, pero desde luego, como persona no puede ser más estúpido y prepotente.
La historia empieza porque el chaval de RedHat expresa de buenas maneras y de forma muy correcta que esto se podría hacer desde espacio de usuario y que quizá no sea el sitio más correcto el Kernel para hacerlo. Una duda razonable, expresada correctamente y que es más o menos discutible, porque como se ve lo que han hecho en Kernel se puede hacer desde espacio de usuario y las distros lo podrían habilitar a voluntad ( luego diremos que si el Kernel pesa y está lleno de mierda ).
Respuesta de Torvalds a la duda: Numbers talk, bullshit walks. The numbers have been quoted. The clear interactive behavior has been seen. And you're just full of bullshit. Come back when you have something working and with numbers and better interactive performance. Until then, nobody cares.
Después de eso es cuando el chaval de RedHat se pega la sobrada de escribir en 6 líneas "el parche" en espacio de usuario que consigue el mismo rendimiento que las 200 líneas del kernel.
#5:
Estando Cristóbal Colón a la mesa con muchos nobles españoles, uno de ellos le dijo: 'Sr. Colón, incluso si vuestra merced no hubiera encontrado las Indias, no nos habría faltado una persona que hubiese emprendido una aventura similar a la suya, aquí, en España que es tierra pródiga en grandes hombres muy entendidos en cosmografía y literatura'. Colón no respondió a estas palabras pero, habiendo solicitado que le trajeran un huevo, lo colocó sobre la mesa y dijo: 'Señores, apuesto con cualquiera de ustedes a que no serán capaces de poner este huevo de pie como yo lo haré, desnudo y sin ayuda ninguna'. Todos lo intentaron sin éxito y cuando el huevo volvió a Colón éste al golpearlo contra la mesa, colocandolo sutilmente lo dejó de pie. Todos los presentes quedaron confundidos y entendieron lo que quería decirles: que después de hecha y vista la hazaña, cualquiera sabe cómo hacerla.
"Right. And that's basically how this "patch" was actually tested
originally - by doing this by hand, without actually having a patch in
hand. I told people: this seems to work really well. Mike made it work
automatically."
Vaya, haciendo noticia de una no-ticia solo porque ataca a Linus.
#9:
#8 En parte la realidad es que mucha gente que colabora con el codigo abierto esta hasta los huevos de supuestas "propuestas" y/o "mejoras" y criticas de boquilla y para proponer/criticar hay millones pero para aportar pocos.
Lo que tendria que hacer el chaval es mandar esas lineas con su propuesta la primera vez.
Vamos si tienes algo que decir dilo con codigo.
De todas formas prepotente si es el comentario, con pasar de el hasta que enviara algo que evaluar llegaba.
#40:
El problema de todo esto es que se va vendido la idea de que el parche milagroso original tiene alguna utilidad para el usuario general, y Lennart viene a decir eso: lo que hace el parche se puede conseguir igual desde espacio de usuario. ¿Se está usando esa funcionalidad? No.
Cuando digo que todo lo que se ha escrito sobre el "famoso" parche no refleja la realidad es porque solo supone una ventaja para el que lance tareas intensivas con la CPU como un 'make -j 64' (construir el núcleo de Linux, por ejemplo, con 64 hilos concurrentes), que se puedan agrupar en el scheduler como un solo trabajo (si no he entendido mal).
Es decir, no va a suponer una ventaja para casi ningún usuario "normal" de escritorio (igual si estás codificando un vídeo con n hilos... pero no sé si las pegas serán de IO entonces). En ese contexto, el usuario que realmente necesita eso tiene la capacidad de hacer los cambios para tener en espacio de usuario ese comportamiento (aunque sea asociado a una sola terminal).
Llegados a este punto tenemos tres cosas:
- El parche original se ha tratado con un sensacionalismo absurdo, y Lennart ha demostrado que no es tan mágico cuando no es ni necesario (Lennart es un crack, de acuerdo que no todo el mundo sabía que se podía hacer algo así).
- Linus está de acuerdo, pero considera que es la obligación del kernel ofrecer esa funcionalidad de forma transparente (con lo que el parche original es más adecuado). Yo personalmente estoy de acuerdo con Linus (si se puede lanzar ese scheduler de forma adaptable, joder... ¡mejor!).
- Hay temas técnicos que son complejos, y es muy difícil explicar las cosas bien y que un público general las entienda; pero si investigamos un poco, podemos llegar a entender qué es lo que pasa realmente y qué diferencias hay con lo que nos cuentan.
editado:
algunas negritas para facilitar la lectura
#17:
Vuestro odio hacia Linus Tordvals me hace más grande. Además me hace gracia que se le acuse de prepotente en Meneame, lugar donde todo el mundo comenta de mala leche como si le hubieran metido un cactus por el culo.
#4 Te doy positivo, gran desarrollador es Lennart aunque no veas como me jodió que dejara PulseAudio a medias, por ejemplo salidas ópticas no están soportadas y hay que recaer directamente sobre alsa, porque se puso a saco con systemd y a parte de el en PulseAudio solo está como constante Colin Guthrie pero se contró en añadir una característica necesaria para integración con KDE4 y no se si ha hecho mucho más.
Estando Cristóbal Colón a la mesa con muchos nobles españoles, uno de ellos le dijo: 'Sr. Colón, incluso si vuestra merced no hubiera encontrado las Indias, no nos habría faltado una persona que hubiese emprendido una aventura similar a la suya, aquí, en España que es tierra pródiga en grandes hombres muy entendidos en cosmografía y literatura'. Colón no respondió a estas palabras pero, habiendo solicitado que le trajeran un huevo, lo colocó sobre la mesa y dijo: 'Señores, apuesto con cualquiera de ustedes a que no serán capaces de poner este huevo de pie como yo lo haré, desnudo y sin ayuda ninguna'. Todos lo intentaron sin éxito y cuando el huevo volvió a Colón éste al golpearlo contra la mesa, colocandolo sutilmente lo dejó de pie. Todos los presentes quedaron confundidos y entendieron lo que quería decirles: que después de hecha y vista la hazaña, cualquiera sabe cómo hacerla.
y #5 si, justamente Linus comenta lo mismo pero de forma menos poética que tú
Anyway, I find it depressing that now that this is solved, people come
out of the woodwork and say "hey you could do this". Where were you
guys a year ago or more?
Tough. I found out that I can solve it using cgroups, I asked people
to comment and help, and I think the kernel approach is wonderful and
way simpler than the scripts I've seen. Yes, I'm biased ("kernels
are easy - user space maintenance is a big pain").
Simply edit your own ~/.bashrc and add this to the end:
>
> if [ "$PS1" ] ; then
> mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$
> echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks
> fi
>
> Then, as the superuser do this:
>
> mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
> mkdir -m 0777 /sys/fs/cgroup/cpu/user
Una vez visto el código el mérito no es el mismo y además no se le puede pedir al usuario que haga eso manualmente, sino podríamos pedirle que hagan otras tareas propias del sistema. En el kernel, mucho más limpio. Ahora, Lennart consigue picar y dejar mal a Linus. Logro desbloqueado.
No veo que tiene de interesante, el propio Linus cuenta como fue así, a mano, como probó la idea, y una vez probada y visto los efectos sugirió a Mike Galbraith que lo implementara como un automatismo en el kernel para que no hiciera falta tocar nada en las distros para que funcionara.
Desde luego, cada thread que leo de Torvalds más estúpido me parece. Habrá hecho mucho por el mundo de la informática, pero desde luego, como persona no puede ser más estúpido y prepotente.
La historia empieza porque el chaval de RedHat expresa de buenas maneras y de forma muy correcta que esto se podría hacer desde espacio de usuario y que quizá no sea el sitio más correcto el Kernel para hacerlo. Una duda razonable, expresada correctamente y que es más o menos discutible, porque como se ve lo que han hecho en Kernel se puede hacer desde espacio de usuario y las distros lo podrían habilitar a voluntad ( luego diremos que si el Kernel pesa y está lleno de mierda ).
Respuesta de Torvalds a la duda: Numbers talk, bullshit walks. The numbers have been quoted. The clear interactive behavior has been seen. And you're just full of bullshit. Come back when you have something working and with numbers and better interactive performance. Until then, nobody cares.
Después de eso es cuando el chaval de RedHat se pega la sobrada de escribir en 6 líneas "el parche" en espacio de usuario que consigue el mismo rendimiento que las 200 líneas del kernel.
#8 En parte la realidad es que mucha gente que colabora con el codigo abierto esta hasta los huevos de supuestas "propuestas" y/o "mejoras" y criticas de boquilla y para proponer/criticar hay millones pero para aportar pocos.
Lo que tendria que hacer el chaval es mandar esas lineas con su propuesta la primera vez.
Vamos si tienes algo que decir dilo con codigo.
De todas formas prepotente si es el comentario, con pasar de el hasta que enviara algo que evaluar llegaba.
#9 Linus es bastante conocido por sus respuestas salidas de tono y varias veces lo han callado, eso no quita que haya contribuido mucho a la informatica en general y que se le este agradecido por crear el kernel linux (que si bien no es la mejor tecnologia, mejor que esperar a hurd). #10 Dejando de lado que sea noticia por atacar a Linus (cosa que no niego), el hecho es que el parche no tiene mucha razon para estar en kernel, menos si siempre se toma el software libre como paradigma de cooperacion, entonces solo hace falta que las distribuciones apliquen el parche en userspace y no saturar (aun mas) el kernel. #13 Totalmente clavado, solo que Linus promete que servira para aumentar el rendimiento del escritorio, cosa que puede ser cierta en algunos caso pero no esta justificado que este en el kernel. #17 Por lo menos no es que los menenantes sean conocidos en varias naciones y en varios idiomas como grandes troles.
De antiguo es sabido que Linus es un troll, pero un troll que pedalea, a diferencia de los trolls que solo ruedan cuesta abajo a ver si pillan a alguien.
#19 Me parece entender que es un conflicto entre que cada distro se las apañe, o que se reconozca el escritorio como parte esencial del sistema. Desde ese punto de vista, y teniendo en cuenta que en el kernel ya se están metiendo mejoras para que el escritorio funcione mejor, podría tener sentido meterlo como parche a modo de reconocimiento de funcionalidad esencial. Al fin y al cabo, las distros más específicas siempre podrían desconectarlo...
#20 Bueno, yo no soy informatico asi que no puedo opinar con toda la autoridad (aunque en un arranque de arrogancia me podria comparar con Con Kolivas), pero yo no veo porque un parche que se supone que es mejor del escritorio (cosa que no es enteramente cierta como dan algunas razones) tiene que saturar aun mas el kernel. Yo prefiero la filosofia UNIX en la cual pequeños programas se comunican entre si en vez de un entorno totalmente centralizado, con la ventaja de poder "desconectar" mas facilmente y que sea mas facil de entender el codigo.
#23 "filosofia UNIX en la cual pequeños programas se comunican entre" #24 "Si algo se puede hacer en userspace es mejor hacerlo ahí"
Bonitas ideas... que llevadas al extremo, conducen al desastre.
A día de hoy cambiar de tarea sigue teniendo un coste prohibitivo en cuanto a rendimiento, y lo que funciona para programas "gordos" no funciona para los elementos que los controlan.
Para el que no se haya leído el parche (¿nadie?), ahí va la descripción:
"This option optimizes the scheduler for common desktop workloads by automatically creating and populating task groups. This separation
of workloads isolates aggressive CPU burners (like build jobs) from
desktop applications. Task group autogeneration is currently based
upon task tty association."
Personalmente, obligar a hacerlo por userspace me parece tanta guarrada como autodetectar por tty... pero bueno, ya se encontrará una solución más elegante. Por ahora parece razonable tener ambas.
#31 Al final me he leido prácticamente todo el hilo y he sacado estas afirmaciones:
- La funcionalidad del núcleo es automática. No tiene interfaz. Sólo se activa o desactiva y nadie más la toca, por lo que Linus la prefiere a tener algo en espacio de usuario con interfaz y que un administrador o usuarios manazas puedan tocar. (Ahora mismo el script de shell deja un directorio con permisos de escritura total 0777 y eso en un sistema multiusuario es malo)
- La agrupación por TTY es un comienzo pero no parece que haya que parar ahí. Se discute hacer pruebas para ver qué agrupaciones de procesos son más beneficiosas.
- Systemd (gestor de arranque de servicios creado por Lennart Potering y que se supone que sustituirá al sysvrc de toda la vida) usa cgroups para agrupar y monitorizar procesos y es por lo que Lennart cree que esta funcionalidad sobra en el núcleo. (Cada uno defendiendo lo que es suyo)
- Linus ve que cualquier programa de espacio de usuario será más complejo de mantener que la solución dada en el núcleo aunque le replican que la versión del núcleo no es genérica y sólo resuelve un problema concreto que poca gente que no sea desarrolladora tiene.
- En cualquier caso se puede desactivar la versión del núcleo y usar un servicio de espacio de usuario.
#26 Te equivocas, esa gente no esta para analizar la "mierda" (como dice linus) que suelta el primero en una lista de correo, si quieres mejorar algo vete siempre con codigo por delante más cuando ya lo habian echo ellos así la primera vez y luego lo que queria era pasarlo al kernel para que fuese automatico.
Más respetuoso si seria el "Show me de code", eso no te lo niego.
#9#8En parte la realidad es que mucha gente que colabora con el codigo abierto esta hasta los huevos de supuestas "propuestas" y/o "mejoras" y criticas de boquilla y para proponer/criticar hay millones pero para aportar pocos.
Lo que tendria que hacer el chaval es mandar esas lineas con su propuesta la primera vez.
Vamos si tienes algo que decir dilo con codigo.
De todas formas prepotente si es el comentario, con pasar de el hasta que enviara algo que evaluar llegaba.
Lo que tendría que haber hecho Linus es alguna de estas dos cosas:
1) Analizar si lo que le decían tenía sentido o no.
2) En el caso de que estuviera muy ocupado, contestar con un escueto "Show me the code" ¿se dice así?
Prejuzgar es disculpable, la mala educación no. Incluso los genios son capaces de quedar como idiotas. Ha sido una lección en toda regla y la moralina es esta:
El sabio aprende incluso del tonto, el tonto no aprende ni siquiera del sabio.
La arrogancia, la prepotencia y la estupidez son la misma cosa.
Admiro a Linus y ha demostrado mucha humildad en muchas ocasiones, pero no en esta ocasión.
#10 Pero no son formas de decirlo como bien apunta #8, ya sabemos quien es Linus.
Por muy genio que sea, que evidentemente no puedo ni quiero negarlo, hay otros genios.
#8 La actitud de Torvalds es habitual en ese mundillo de hackers. Parece mucho más rudo de lo que realmente es. Normalmente Torvalds reacciona con esa virulencia cuando alguien trata de argumentar con ideas, según el parecer de Torvalds, equivocadas, como es el caso.
Pero vamos, que esas formas tan ásperas sirven para filtrar ideas mediocres y que los que realmente tengan algo que aportar se lo piensen dos veces.
En todo caso, Torvalds es tan rudo con las ideas mediocres como agradecido con las brillantes.
#38 La actitud del sr. Torvalds es la de un perfecto memo arrogante, motivo por el cual mucha gente que podría aportar cosas pasa siete pueblos del mundo elitista y estúpido que hay entorno al kernel, donde parece que todas las vacas sagradas van con una escoba metida por el culo, y donde hace tiempo que el buen rollo se esfumó.
Pero bueno, si para ti es "un filtro de ideas mediocres", es tu opinión. Otros proyectos libres tienen igual o parecida importancia y no se respiran esos aires, esa es la mía
Para #41. Casi lo veo como una conversación privada que se ha realizado en un espacio público. Estamos prejuzgando demasiado a los contertulios, que por si fuera poco dedican su tiempo a discutir como mejorar de la forma más adecuada Software Libre de primera categoría.
"Right. And that's basically how this "patch" was actually tested
originally - by doing this by hand, without actually having a patch in
hand. I told people: this seems to work really well. Mike made it work
automatically."
Algo que no se si se ha entendido de este parche es que no tiene nada que ver con escritorios mas rápidos... al parecer, y digo esto sin haber probado ningún parche, solo leyendo los hilos de la discusión, encuentro que se habla principalmente de que permite priorizar ramas de procesos, pero en TTY, osea en la consola... no sirve para el xserver... ademas es solamente para los que le meten caña a bocha a la maquina, osea compilan código usando varios procesos..
La noticia se supone que es el que alguien haya hecho algo similar en 4 líneas en BASH. Lo de la discusión es un tema a parte creo yo. Pero bueno, para todo propósito, sea el que sea, siempre hay excusa.
Vuestro odio hacia Linus Tordvals me hace más grande. Además me hace gracia que se le acuse de prepotente en Meneame, lugar donde todo el mundo comenta de mala leche como si le hubieran metido un cactus por el culo.
Menuda chorrada de entrada, he votado sensacionalista.
LKML, es una lista de correo muy particular. En ella hay mucho patch, mucha discusion, mucho flame, y mucho insulto. Esto que acabo de decir NO es noticia, todo el mundo que haya leido la lista mas de 10 minutos lo sabe. Asi que es normal que a Linus, o a cualquier otro, se le responda con patches, y que los insultos caigan.
No se, releo la entradilla de #0, y es que parece escrita por un periodista deportivo ("Mourinho comio lentejas, y los gases le estropearon la siesta"; una observacion harto relevante para entender su obra y/o metodologia de trabajo). Y luego encima se dice la chorrada del patch "milagro". Wtf?
No entiendo la postura de Linus. Si algo se puede hacer en userspace es mejor hacerlo ahí. Menos problemas de seguridad, menos líneas que auditar en el núcleo y unas instrucciones fáciles de seguir en un script de shell. El propio núcleo tiene cada vez más la política de sacar a userspace lo que no sea imprescindible.
Acabo de poner a funcionar el script en 1 minuto y poniendo el mount en el /etc/fstab funciona de forma totalmente automática y desatendida, no hay que estar haciéndolo cada vez.
#24 Linus siempre ha seguido la política de meter en el núcleo cosas si con ello se mejora mucho el rendimiento, incluso llegó a meter un servidor web (que no tuvo éxito). En parte el viejo y famoso debate Linus vs. Tanenbaum (año 1992, cuando Linus sólo llevaba unos meses programando su núcleo) fue sobre esta cuestión.
#28 El problema es que, al menos en mi debian, /dev/cgroups o /sys/fs/crgroups no existen. Existe un paquete en los repositorios con el sospechoso nombre cd cgroups, pero no lo he mirado aún.
En una noticia de hace unos meses, puesta en Menéame, decía que un chaval había calculado el tanto por ciento de probabilidades que tenía una noticia de llegar a portada.
Me inclino a pensar que si la noticia tiene que ver con Linux es del 100% de posibilidades
Las cosas como son, no sé porque mucha gente piensa que todos deberían ser informáticos, cada uno tiene su especialidad, no tenemos porque saber todo de todo, a veces simplemente me interesa que algo funcione, sin que tenga que preocuparme de hacerlo funcionar yo.
El problema de todo esto es que se va vendido la idea de que el parche milagroso original tiene alguna utilidad para el usuario general, y Lennart viene a decir eso: lo que hace el parche se puede conseguir igual desde espacio de usuario. ¿Se está usando esa funcionalidad? No.
Cuando digo que todo lo que se ha escrito sobre el "famoso" parche no refleja la realidad es porque solo supone una ventaja para el que lance tareas intensivas con la CPU como un 'make -j 64' (construir el núcleo de Linux, por ejemplo, con 64 hilos concurrentes), que se puedan agrupar en el scheduler como un solo trabajo (si no he entendido mal).
Es decir, no va a suponer una ventaja para casi ningún usuario "normal" de escritorio (igual si estás codificando un vídeo con n hilos... pero no sé si las pegas serán de IO entonces). En ese contexto, el usuario que realmente necesita eso tiene la capacidad de hacer los cambios para tener en espacio de usuario ese comportamiento (aunque sea asociado a una sola terminal).
Llegados a este punto tenemos tres cosas:
- El parche original se ha tratado con un sensacionalismo absurdo, y Lennart ha demostrado que no es tan mágico cuando no es ni necesario (Lennart es un crack, de acuerdo que no todo el mundo sabía que se podía hacer algo así).
- Linus está de acuerdo, pero considera que es la obligación del kernel ofrecer esa funcionalidad de forma transparente (con lo que el parche original es más adecuado). Yo personalmente estoy de acuerdo con Linus (si se puede lanzar ese scheduler de forma adaptable, joder... ¡mejor!).
- Hay temas técnicos que son complejos, y es muy difícil explicar las cosas bien y que un público general las entienda; pero si investigamos un poco, podemos llegar a entender qué es lo que pasa realmente y qué diferencias hay con lo que nos cuentan.
Como no he entendido demasiado de la noticia, he curioseado por el blog que la publica. Y he encontrado este interesantísimo espacio donde se habla de la evolución (es el último enlace de la cabecera del blog): http://blog.christophersmart.com/unmasking-evolution/
Bueno, lo digo por si alguien quiere leerlo, ya que se ponen textos en que se cuestiona la Teoría de la Evolución y demás (creo haber entendido). Nada, para los que como yo se hayan perdido con lo del 'parche milagro' y quieran probar con otra cosa.
Lo que no comprendo es por qué atacáis a las personas...
Si vais al contenido, la noticia es maravillosa: una mejora simple y gratuita gracias al código abierto que usa GNU/linux.
Comentarios
Dupe y portada: El parche de 200 líneas para el kernel Linux que hace maravillas [ENG]
El parche de 200 líneas para el kernel Linux que h...
phoronix.comLa discusión entre Linus y Lennart no tiene desperdicio http://lkml.org/lkml/2010/11/16/298
#2 No te columpies anda. Lee las cosas antes de hacer el ridículo.
#1 Rectifico. ;?
no se leer ... sorry.
Para cuándo el Lennartix?
#4 Te doy positivo, gran desarrollador es Lennart aunque no veas como me jodió que dejara PulseAudio a medias, por ejemplo salidas ópticas no están soportadas y hay que recaer directamente sobre alsa, porque se puso a saco con systemd y a parte de el en PulseAudio solo está como constante Colin Guthrie pero se contró en añadir una característica necesaria para integración con KDE4 y no se si ha hecho mucho más.
Estando Cristóbal Colón a la mesa con muchos nobles españoles, uno de ellos le dijo: 'Sr. Colón, incluso si vuestra merced no hubiera encontrado las Indias, no nos habría faltado una persona que hubiese emprendido una aventura similar a la suya, aquí, en España que es tierra pródiga en grandes hombres muy entendidos en cosmografía y literatura'. Colón no respondió a estas palabras pero, habiendo solicitado que le trajeran un huevo, lo colocó sobre la mesa y dijo: 'Señores, apuesto con cualquiera de ustedes a que no serán capaces de poner este huevo de pie como yo lo haré, desnudo y sin ayuda ninguna'. Todos lo intentaron sin éxito y cuando el huevo volvió a Colón éste al golpearlo contra la mesa, colocandolo sutilmente lo dejó de pie. Todos los presentes quedaron confundidos y entendieron lo que quería decirles: que después de hecha y vista la hazaña, cualquiera sabe cómo hacerla.
#15 goto #5, excusa ninguna, aunque está bién, hubiese sido realmente espectacular si lo hubiese hecho antes del parche de Linus.
#5 grande colón. asturiano, sin duda.
#8 goto #5
y #5 si, justamente Linus comenta lo mismo pero de forma menos poética que tú
Anyway, I find it depressing that now that this is solved, people come
out of the woodwork and say "hey you could do this". Where were you
guys a year ago or more?
Tough. I found out that I can solve it using cgroups, I asked people
to comment and help, and I think the kernel approach is wonderful and
way simpler than the scripts I've seen. Yes, I'm biased ("kernels
are easy - user space maintenance is a big pain").
#15
Simply edit your own ~/.bashrc and add this to the end:
>
> if [ "$PS1" ] ; then
> mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$
> echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks
> fi
>
> Then, as the superuser do this:
>
> mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
> mkdir -m 0777 /sys/fs/cgroup/cpu/user
Una vez visto el código el mérito no es el mismo y además no se le puede pedir al usuario que haga eso manualmente, sino podríamos pedirle que hagan otras tareas propias del sistema. En el kernel, mucho más limpio. Ahora, Lennart consigue picar y dejar mal a Linus. Logro desbloqueado.
No veo que tiene de interesante, el propio Linus cuenta como fue así, a mano, como probó la idea, y una vez probada y visto los efectos sugirió a Mike Galbraith que lo implementara como un automatismo en el kernel para que no hiciera falta tocar nada en las distros para que funcionara.
Desde luego, cada thread que leo de Torvalds más estúpido me parece. Habrá hecho mucho por el mundo de la informática, pero desde luego, como persona no puede ser más estúpido y prepotente.
La historia empieza porque el chaval de RedHat expresa de buenas maneras y de forma muy correcta que esto se podría hacer desde espacio de usuario y que quizá no sea el sitio más correcto el Kernel para hacerlo. Una duda razonable, expresada correctamente y que es más o menos discutible, porque como se ve lo que han hecho en Kernel se puede hacer desde espacio de usuario y las distros lo podrían habilitar a voluntad ( luego diremos que si el Kernel pesa y está lleno de mierda ).
Respuesta de Torvalds a la duda: Numbers talk, bullshit walks. The numbers have been quoted. The clear interactive behavior has been seen. And you're just full of bullshit. Come back when you have something working and with numbers and better interactive performance. Until then, nobody cares.
Después de eso es cuando el chaval de RedHat se pega la sobrada de escribir en 6 líneas "el parche" en espacio de usuario que consigue el mismo rendimiento que las 200 líneas del kernel.
#8 En parte la realidad es que mucha gente que colabora con el codigo abierto esta hasta los huevos de supuestas "propuestas" y/o "mejoras" y criticas de boquilla y para proponer/criticar hay millones pero para aportar pocos.
Lo que tendria que hacer el chaval es mandar esas lineas con su propuesta la primera vez.
Vamos si tienes algo que decir dilo con codigo.
De todas formas prepotente si es el comentario, con pasar de el hasta que enviara algo que evaluar llegaba.
#9 Linus es bastante conocido por sus respuestas salidas de tono y varias veces lo han callado, eso no quita que haya contribuido mucho a la informatica en general y que se le este agradecido por crear el kernel linux (que si bien no es la mejor tecnologia, mejor que esperar a hurd).
#10 Dejando de lado que sea noticia por atacar a Linus (cosa que no niego), el hecho es que el parche no tiene mucha razon para estar en kernel, menos si siempre se toma el software libre como paradigma de cooperacion, entonces solo hace falta que las distribuciones apliquen el parche en userspace y no saturar (aun mas) el kernel.
#13 Totalmente clavado, solo que Linus promete que servira para aumentar el rendimiento del escritorio, cosa que puede ser cierta en algunos caso pero no esta justificado que este en el kernel.
#17 Por lo menos no es que los menenantes sean conocidos en varias naciones y en varios idiomas como grandes troles.
De antiguo es sabido que Linus es un troll, pero un troll que pedalea, a diferencia de los trolls que solo ruedan cuesta abajo a ver si pillan a alguien.
#19 Me parece entender que es un conflicto entre que cada distro se las apañe, o que se reconozca el escritorio como parte esencial del sistema. Desde ese punto de vista, y teniendo en cuenta que en el kernel ya se están metiendo mejoras para que el escritorio funcione mejor, podría tener sentido meterlo como parche a modo de reconocimiento de funcionalidad esencial. Al fin y al cabo, las distros más específicas siempre podrían desconectarlo...
#20 Bueno, yo no soy informatico asi que no puedo opinar con toda la autoridad (aunque en un arranque de arrogancia me podria comparar con Con Kolivas), pero yo no veo porque un parche que se supone que es mejor del escritorio (cosa que no es enteramente cierta como dan algunas razones) tiene que saturar aun mas el kernel. Yo prefiero la filosofia UNIX en la cual pequeños programas se comunican entre si en vez de un entorno totalmente centralizado, con la ventaja de poder "desconectar" mas facilmente y que sea mas facil de entender el codigo.
#23 "filosofia UNIX en la cual pequeños programas se comunican entre"
#24 "Si algo se puede hacer en userspace es mejor hacerlo ahí"
Bonitas ideas... que llevadas al extremo, conducen al desastre.
A día de hoy cambiar de tarea sigue teniendo un coste prohibitivo en cuanto a rendimiento, y lo que funciona para programas "gordos" no funciona para los elementos que los controlan.
Para el que no se haya leído el parche (¿nadie?), ahí va la descripción:
"This option optimizes the scheduler for common desktop workloads by
automatically creating and populating task groups. This separation
of workloads isolates aggressive CPU burners (like build jobs) from
desktop applications. Task group autogeneration is currently based
upon task tty association."
Personalmente, obligar a hacerlo por userspace me parece tanta guarrada como autodetectar por tty... pero bueno, ya se encontrará una solución más elegante. Por ahora parece razonable tener ambas.
#31 Al final me he leido prácticamente todo el hilo y he sacado estas afirmaciones:
- La funcionalidad del núcleo es automática. No tiene interfaz. Sólo se activa o desactiva y nadie más la toca, por lo que Linus la prefiere a tener algo en espacio de usuario con interfaz y que un administrador o usuarios manazas puedan tocar. (Ahora mismo el script de shell deja un directorio con permisos de escritura total 0777 y eso en un sistema multiusuario es malo)
- La agrupación por TTY es un comienzo pero no parece que haya que parar ahí. Se discute hacer pruebas para ver qué agrupaciones de procesos son más beneficiosas.
- Systemd (gestor de arranque de servicios creado por Lennart Potering y que se supone que sustituirá al sysvrc de toda la vida) usa cgroups para agrupar y monitorizar procesos y es por lo que Lennart cree que esta funcionalidad sobra en el núcleo. (Cada uno defendiendo lo que es suyo)
- Linus ve que cualquier programa de espacio de usuario será más complejo de mantener que la solución dada en el núcleo aunque le replican que la versión del núcleo no es genérica y sólo resuelve un problema concreto que poca gente que no sea desarrolladora tiene.
- En cualquier caso se puede desactivar la versión del núcleo y usar un servicio de espacio de usuario.
#19 Gracias pero llevo 16 años con linux y ya conozco un poco de que va todo.
Por cierto lo que dices a #13 en que te basas?
#26 Te equivocas, esa gente no esta para analizar la "mierda" (como dice linus) que suelta el primero en una lista de correo, si quieres mejorar algo vete siempre con codigo por delante más cuando ya lo habian echo ellos así la primera vez y luego lo que queria era pasarlo al kernel para que fuese automatico.
Más respetuoso si seria el "Show me de code", eso no te lo niego.
#9 #8 En parte la realidad es que mucha gente que colabora con el codigo abierto esta hasta los huevos de supuestas "propuestas" y/o "mejoras" y criticas de boquilla y para proponer/criticar hay millones pero para aportar pocos.
Lo que tendria que hacer el chaval es mandar esas lineas con su propuesta la primera vez.
Vamos si tienes algo que decir dilo con codigo.
De todas formas prepotente si es el comentario, con pasar de el hasta que enviara algo que evaluar llegaba.
Lo que tendría que haber hecho Linus es alguna de estas dos cosas:
1) Analizar si lo que le decían tenía sentido o no.
2) En el caso de que estuviera muy ocupado, contestar con un escueto "Show me the code" ¿se dice así?
Prejuzgar es disculpable, la mala educación no. Incluso los genios son capaces de quedar como idiotas. Ha sido una lección en toda regla y la moralina es esta:
El sabio aprende incluso del tonto, el tonto no aprende ni siquiera del sabio.
La arrogancia, la prepotencia y la estupidez son la misma cosa.
Admiro a Linus y ha demostrado mucha humildad en muchas ocasiones, pero no en esta ocasión.
#10 Pero no son formas de decirlo como bien apunta #8, ya sabemos quien es Linus.
Por muy genio que sea, que evidentemente no puedo ni quiero negarlo, hay otros genios.
#8 La actitud de Torvalds es habitual en ese mundillo de hackers. Parece mucho más rudo de lo que realmente es. Normalmente Torvalds reacciona con esa virulencia cuando alguien trata de argumentar con ideas, según el parecer de Torvalds, equivocadas, como es el caso.
Pero vamos, que esas formas tan ásperas sirven para filtrar ideas mediocres y que los que realmente tengan algo que aportar se lo piensen dos veces.
En todo caso, Torvalds es tan rudo con las ideas mediocres como agradecido con las brillantes.
#38 La actitud del sr. Torvalds es la de un perfecto memo arrogante, motivo por el cual mucha gente que podría aportar cosas pasa siete pueblos del mundo elitista y estúpido que hay entorno al kernel, donde parece que todas las vacas sagradas van con una escoba metida por el culo, y donde hace tiempo que el buen rollo se esfumó.
Pero bueno, si para ti es "un filtro de ideas mediocres", es tu opinión. Otros proyectos libres tienen igual o parecida importancia y no se respiran esos aires, esa es la mía
Para #41. Casi lo veo como una conversación privada que se ha realizado en un espacio público. Estamos prejuzgando demasiado a los contertulios, que por si fuera poco dedican su tiempo a discutir como mejorar de la forma más adecuada Software Libre de primera categoría.
#41 Algunos tienen la piel muy fina...
#41 Si no te gusta, de jodes... y si no puedes callarme la boca con 4 líneas de código, no pierdo nada por que me dejes de hablar.
PD: ...y he ahí cómo funciona el filtro
Respuesta de Linus:
"Right. And that's basically how this "patch" was actually tested
originally - by doing this by hand, without actually having a patch in
hand. I told people: this seems to work really well. Mike made it work
automatically."
http://lkml.org/lkml/2010/11/16/351
Vaya, haciendo noticia de una no-ticia solo porque ataca a Linus.
#10
En mi opinión esa respuesta de Linus lo ha terminado por dejar todo claro y le ha callado la boca al otro, sin ningún tipo de arrogancia.
¿alguno lo ha probado ya?
¿Qué tal va?
Algo que no se si se ha entendido de este parche es que no tiene nada que ver con escritorios mas rápidos... al parecer, y digo esto sin haber probado ningún parche, solo leyendo los hilos de la discusión, encuentro que se habla principalmente de que permite priorizar ramas de procesos, pero en TTY, osea en la consola... no sirve para el xserver... ademas es solamente para los que le meten caña a bocha a la maquina, osea compilan código usando varios procesos..
No tengo el directorio /sys/fs/cgroup/ al parecer habrá que instalar alguna cosilla, o recompilar el kernel, no?
La noticia se supone que es el que alguien haya hecho algo similar en 4 líneas en BASH. Lo de la discusión es un tema a parte creo yo. Pero bueno, para todo propósito, sea el que sea, siempre hay excusa.
#15 Igual de aquí sacas algo http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
Vaya trol que está hecho Torvalds. Tanto programar en C debe de afectar al cerebro
Vuestro odio hacia Linus Tordvals me hace más grande. Además me hace gracia que se le acuse de prepotente en Meneame, lugar donde todo el mundo comenta de mala leche como si le hubieran metido un cactus por el culo.
LoL. Esto me recuerda a los viejos tiempos.
Menuda chorrada de entrada, he votado sensacionalista.
LKML, es una lista de correo muy particular. En ella hay mucho patch, mucha discusion, mucho flame, y mucho insulto. Esto que acabo de decir NO es noticia, todo el mundo que haya leido la lista mas de 10 minutos lo sabe. Asi que es normal que a Linus, o a cualquier otro, se le responda con patches, y que los insultos caigan.
No se, releo la entradilla de #0, y es que parece escrita por un periodista deportivo ("Mourinho comio lentejas, y los gases le estropearon la siesta"; una observacion harto relevante para entender su obra y/o metodologia de trabajo). Y luego encima se dice la chorrada del patch "milagro". Wtf?
No entiendo la postura de Linus. Si algo se puede hacer en userspace es mejor hacerlo ahí. Menos problemas de seguridad, menos líneas que auditar en el núcleo y unas instrucciones fáciles de seguir en un script de shell. El propio núcleo tiene cada vez más la política de sacar a userspace lo que no sea imprescindible.
Acabo de poner a funcionar el script en 1 minuto y poniendo el mount en el /etc/fstab funciona de forma totalmente automática y desatendida, no hay que estar haciéndolo cada vez.
#24 Linus siempre ha seguido la política de meter en el núcleo cosas si con ello se mejora mucho el rendimiento, incluso llegó a meter un servidor web (que no tuvo éxito). En parte el viejo y famoso debate Linus vs. Tanenbaum (año 1992, cuando Linus sólo llevaba unos meses programando su núcleo) fue sobre esta cuestión.
El parche original no sirve en Ubuntu, hay que hacerle unas modificaciones: http://www.muylinux.com/2010/11/19/%C2%BFrecordais-el-milagroso-parche-de-las-200-lineas-de-codigo-podeis-lograr-lo-mismo-en-2-minutos-sin-parchear-el-kernel
alguien sabe si para Debian se hace igual que para Ubuntu?
#28 El problema es que, al menos en mi debian, /dev/cgroups o /sys/fs/crgroups no existen. Existe un paquete en los repositorios con el sospechoso nombre cd cgroups, pero no lo he mirado aún.
En una noticia de hace unos meses, puesta en Menéame, decía que un chaval había calculado el tanto por ciento de probabilidades que tenía una noticia de llegar a portada.
Me inclino a pensar que si la noticia tiene que ver con Linux es del 100% de posibilidades
#35
Es fácil:
http://www.meneame.net/search.php?q=linux&w=links&p=&s=published&h=&o=date&u= / http://www.meneame.net/search.php?q=linux&w=links&p=&s=&h=&o=date&u= = 17.5%
#36 Las matemáticas son las matemáticas. Sin embargo, da la sensación de ser más...
Saludos
Las cosas como son, no sé porque mucha gente piensa que todos deberían ser informáticos, cada uno tiene su especialidad, no tenemos porque saber todo de todo, a veces simplemente me interesa que algo funcione, sin que tenga que preocuparme de hacerlo funcionar yo.
El problema de todo esto es que se va vendido la idea de que el parche milagroso original tiene alguna utilidad para el usuario general, y Lennart viene a decir eso: lo que hace el parche se puede conseguir igual desde espacio de usuario. ¿Se está usando esa funcionalidad? No.
Cuando digo que todo lo que se ha escrito sobre el "famoso" parche no refleja la realidad es porque solo supone una ventaja para el que lance tareas intensivas con la CPU como un 'make -j 64' (construir el núcleo de Linux, por ejemplo, con 64 hilos concurrentes), que se puedan agrupar en el scheduler como un solo trabajo (si no he entendido mal).
Es decir, no va a suponer una ventaja para casi ningún usuario "normal" de escritorio (igual si estás codificando un vídeo con n hilos... pero no sé si las pegas serán de IO entonces). En ese contexto, el usuario que realmente necesita eso tiene la capacidad de hacer los cambios para tener en espacio de usuario ese comportamiento (aunque sea asociado a una sola terminal).
Llegados a este punto tenemos tres cosas:
- El parche original se ha tratado con un sensacionalismo absurdo, y Lennart ha demostrado que no es tan mágico cuando no es ni necesario (Lennart es un crack, de acuerdo que no todo el mundo sabía que se podía hacer algo así).
- Linus está de acuerdo, pero considera que es la obligación del kernel ofrecer esa funcionalidad de forma transparente (con lo que el parche original es más adecuado). Yo personalmente estoy de acuerdo con Linus (si se puede lanzar ese scheduler de forma adaptable, joder... ¡mejor!).
- Hay temas técnicos que son complejos, y es muy difícil explicar las cosas bien y que un público general las entienda; pero si investigamos un poco, podemos llegar a entender qué es lo que pasa realmente y qué diferencias hay con lo que nos cuentan.
Como no he entendido demasiado de la noticia, he curioseado por el blog que la publica. Y he encontrado este interesantísimo espacio donde se habla de la evolución (es el último enlace de la cabecera del blog):
http://blog.christophersmart.com/unmasking-evolution/
Bueno, lo digo por si alguien quiere leerlo, ya que se ponen textos en que se cuestiona la Teoría de la Evolución y demás (creo haber entendido). Nada, para los que como yo se hayan perdido con lo del 'parche milagro' y quieran probar con otra cosa.
Lo que no comprendo es por qué atacáis a las personas...
Si vais al contenido, la noticia es maravillosa: una mejora simple y gratuita gracias al código abierto que usa GNU/linux.
Si los que tenéis Linux lo queréis probar, aquí se explica muy bien:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
Nota: Yo lo he probado en Ubuntu 10.4 de 32bits y en Ubuntu 9.10 de 64 bits y la mejora en el rendimiento es claramente perceptible.
#47 Te doy toda la razón. Lo acabo de poner en mi Eeepc 901 con Ubuntu 10.04 y la mejora en la latencia es realmente apreciable.
Yo uso Ubuntu, ¿Puedo instalarlo?
Hay una frase famosa de Alan Kay contra Dijkstra que dice "en informática, la arrogancia se mide en nanodijkstras".
Vista la contestación de Linus, creo que habría que actualizar el patrón y empezar a medirla en picotorvalds.
Algo más explicado: http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html