Hoy vamos a romper dos mitos: que colaborar en un proyecto de Software Libre es una tarea siempre agradable y que en Navidad todos estamos de buen humor. Y es que no hay más que ver las primeras líneas de la respuesta de Linus Torvalds a Mauro Carvalho, empleado de Red Hat y responsable de los drivers multimedia del kernel Linux, en la lista de correo del proyecto hace un par de días. Enlace a conversación: http://article.gmane.org/gmane.linux.kernel/1414106
#16:
#11 Te lo han machacado todo lo que quieras, y por una buena razón: escribir código lleno de GOTO lo convierte en inmantenible.
Pero, ¿sabes una cosa? A la hora de la verdad... cuando acaba todo compilado, enlazado y listo en código ejecutable... ¡está lleno de GOTO! Los JMP de ensamblador, no son otra cosa que GOTO. Todo lo que escribes de forma ordenada y bonita en tu lenguaje preferido (u odiado), acaba convertido en un amasijo infernal de GOTO por todos lados.
El motivo para usarlos en el kernel, es simple: ahorran una mierda de tiempo de ejecución, pero la ahorran millones de veces. Y eso, en el kernel, importa (aunque tampoco sin pasarse, claro).
#36:
#11 Pasa una cosa, y es que muchas veces en el kernel hay flujos de ejecución bastante engorrosos de tratar si se utilizan if-else a rajatabla, que encima deterioran el rendimiento si no se utilizan adecuadamente (fíjate que existen hasta macros para optimizar saltos a nivel de núcleo: likely() y unlikely()).
Es un uso muy puntual y tiene su razón de ser, pero lo suyo es no utilizar gotos jamás, y en el núcleo (como normal general), solo si la alternativa es una penalización al rendimiento.
#23:
El tema de los GOTO creo que lo machacan sobretodo por qué una aplicación llena de GOTO es un infierno para el siguiente (y hasta para ti después de una semana) que le toque repasar el código. Pero si te toca programar un kernel es que eres ya un verdadero crack y cualquier optimización que puedas hacer pesa más aunque te acabe quedando un código infumable.
#33:
#11 A mí lo que me flipa es que siga existiendo gente que piensa que determinadas posibilidades de un lenguaje no se deben usar por que no y punto (y luego les ves haciendo aberraciones peores, como acceder a una dirección de memoria no válida por no usar un break y decir que como no la modifican no pasa nada ). Yo no he usado un goto en la vida, pero un goto end o similar es perfectamente claro y simple, se hace rápido y evita cosas más complicadas y menos eficientes, por ejemplo.
#1:
Si se hubieran pegado cuatro voces a algún otro proyecto que yo me se probablemente Linux ahora mismo sería relevante en el escritorio...
#18:
#1 A los que complicaron el GNOME de Ubuntu, ¡golpe de remo!
#11#13#15 Hay quien opina que los gotos son aceptables en contadas ocasiones. No olvidemos tampoco que C es considerado, a día de hoy, un lenguaje de medio/bajo nivel.
#1 No creo que la relevancia de los proyectos en el entorno de Linux dependa de rapapolvos. ¿A caso crees que la relevancia que tiene Linux en cuanto al sector profesional y más concretamente en servidores la tiene, por ejemplo, Microsoft? Creo que es más una cuestión de filosofía de trabajo para cada cosa. Los proyectos open source tienen una metodología y los de software cerrado en ocasiones otra.
#2 No creo que se trate de eso, pero a veces hay que dejar ciertas cosas claras. Es mejor leer la respuesta completa, y sí, es una bronca, pero después de leerlo es una bronca merecida. No tiene sentido que mañana windows saque una actualización y dejen de funcionar programas a causa de ello (sobre todo si están muy extendidos), y luego alguien diga: "No, si es que lo que tiene fallos son los otros programas".
#42 Realmente creo que esa es la parte más ofensiva, lo demás es una crítica muy razonada con alguna ofensa insertada por ahí.
#1 A los que complicaron el GNOME de Ubuntu, ¡golpe de remo!
#11#13#15 Hay quien opina que los gotos son aceptables en contadas ocasiones. No olvidemos tampoco que C es considerado, a día de hoy, un lenguaje de medio/bajo nivel.
Pues quizás las formas le pierden , pero no debe faltar razón a Linus, si encima de un error lo ha intentado arreglar con una parche de mierda (según sus palabras).
#6, pues la verdad es que sí, el arreglo era una mierda hecha con desgana...
The whole patch is incredibly broken shit. It adds an
insane error code (ENOENT), and then because it's so insane, it adds a
few places to fix it up ("ret == -ENOENT ? -EINVAL : ret").
En lugar de corregir el error, lo "rodeó" con un if en los returns.....
Seguramente su buzón esté lleno de estupideces y al final sus correos terminen siendo «fucks» por todos los lados, y debe de ser molesto que alguien que se entiende es un profesional en el mantenimiento del kernel cuestione o diga ciertas cosas, porque al fin y al cabo entorpece tu propio trabajo.
Independientemente de su estilo personal, me parece importantísimo que en un proyecto tan grande (en complejidad, y en número de desarrolladores) como el kernel de Linux, haya una figura que sea capaz de cantarle las cuarenta a los colaboradores de cierto rango cuando la cagan.
Si no, pasa lo que en otras meritocracias, que al final el proyecto se va a la mierda por culpa de ciertas malas decisiones tomadas por gente "intocable", las cuales hay que aceptar por el mero hecho de que las ha tomado quien las ha tomado. Y eso mata un proyecto tanto técnicamente, como en el plano personal (la motivación de los programadores "junior" por los suelos).
Además, no es lo más educado del mundo, pero consigue lo que (supongo) persigue, que es el efecto contundencia y que se le quite la chulería al listo de turno. Y si no, mirad su email previo a ver qué humillos tenía el tal Mauro.
Desgraciadamente, el mundo de la informática está repleto de tipos prepotentes, agresivos y maleducados. Eso y las horas extras, hacen que nuestra profesión, que podría ser mucho más apasionante, sea a veces tan desagradable.
Odio las noticias de ingeniería informática, programación y demás fanfarria. No me entero de un carajo
Eso sí, la discusión sobre el comando goto deja ver que la informática es claramente una ingeniería más, de un nivel diferente al que los de estructuras, electricidad, genética, etc, pero ingeniería al fin y al cabo.
ctrl = uvc_find_control(chain, v4l2_ctrl->id, &mapping);
if (ctrl == NULL)
A mi lo que me flipa es que usen GOTO en el kernel, después de todo lo que me han machacado con que es una mala práctica ... (Lógicamente estará justificado).
#13#15 Pues yo creo que está justificado, pues como dice #16, hablamos del código de un Kernel y no de una aplicación. Esto implica que debe estar mucho mejor optimizado, y además "sólo" usan una etiqueta (done), con lo que tampoco será tan difícil de mantener...
Lógicamente nos machacan tanto porque en general no se debe usar, pero como en todo, hay excepciones y estas están justificadas.
#16 de hecho importa mucho creo yo. Si trabajan a bajo nivel, trabajan a bajo nivel. Lo hacen por una buena causa al fin y al cabo. Si estuvieran locos, programarían la totalidad del kernel en asm.
#13 el código, una vez compilado, no deja de tener cienmil gotos por todas partes (bueno goto no realmente, pero una clausula que se comporta de la misma forma)
Estos pavos quieren programar lo más parecido al lenguaje máquina posible. Tienen un coco muy desarrollado para la causa y buscan ahorrar el tiempo de ejecución al máximo.
#11 Te lo han machacado todo lo que quieras, y por una buena razón: escribir código lleno de GOTO lo convierte en inmantenible.
Pero, ¿sabes una cosa? A la hora de la verdad... cuando acaba todo compilado, enlazado y listo en código ejecutable... ¡está lleno de GOTO! Los JMP de ensamblador, no son otra cosa que GOTO. Todo lo que escribes de forma ordenada y bonita en tu lenguaje preferido (u odiado), acaba convertido en un amasijo infernal de GOTO por todos lados.
El motivo para usarlos en el kernel, es simple: ahorran una mierda de tiempo de ejecución, pero la ahorran millones de veces. Y eso, en el kernel, importa (aunque tampoco sin pasarse, claro).
#11 Haz una búsqueda rápida y verás que el kernel de linux está lleno de gotos. Los usan normalmente como punto de salida de funciones cuando una función tiene varios puntos de salida y hay que hacer algún trabajo de "limpieza" antes de salir. En lugar de copiar el mismo trabajo en cada punto de salida, lo ponen en un solo punto y saltan a él con goto donde hace falta.
#11 A mí lo que me flipa es que siga existiendo gente que piensa que determinadas posibilidades de un lenguaje no se deben usar por que no y punto (y luego les ves haciendo aberraciones peores, como acceder a una dirección de memoria no válida por no usar un break y decir que como no la modifican no pasa nada ). Yo no he usado un goto en la vida, pero un goto end o similar es perfectamente claro y simple, se hace rápido y evita cosas más complicadas y menos eficientes, por ejemplo.
#11 Pasa una cosa, y es que muchas veces en el kernel hay flujos de ejecución bastante engorrosos de tratar si se utilizan if-else a rajatabla, que encima deterioran el rendimiento si no se utilizan adecuadamente (fíjate que existen hasta macros para optimizar saltos a nivel de núcleo: likely() y unlikely()).
Es un uso muy puntual y tiene su razón de ser, pero lo suyo es no utilizar gotos jamás, y en el núcleo (como normal general), solo si la alternativa es una penalización al rendimiento.
#11 Sé que mi respuesta es redundante, pero en resumidas cuentas, el problema es que se tiende a usar mal. Usarlo sólo porque existe es una idiotez. Usarlo porque has estudiado los pros y los contras es ingeniería.
Hablo de debida justificación porque en el propio kernel no suele haber muchos bucles que digamos, todo son llamadas a sistema que acceden a dispositivos. El planificador y gestores de memoria es de lo poco que puede tener varios bucles. Si está lleno de gotos estás metiendo saltos incondicionales por un tubo, además de los propios de la función. Eso ya sin entrar en el código espagueti que puede crearse.
Está claro también que te ahorras llamar a una función común por lo que evitas pasos de parámetros de forma continuada, todos sabemos que en el kernel hay que perder el mínimo tiempo posible ya que son las aplicaciones de espacio de usuario las que deben usar la CPU, no el núcleo del sistema operativo. Por ello también las aplicaciones de espacio de usuario no deben abusar de las llamadas a sistema por lo costoso de los cambios de contexto.
Lo que digo siempre en estos hilos: me encantan los flames de Linus.
Y no solo por la trolleada y tal, sino más bien por todo lo que aprendo. Y eso que trata de algo que no creo que sea capaz de hacer nunca, como es la programación a "bajo nivel".
El tema de este hilo ya lo he visto en otras discusiones: la primera regla del club del kernel es no romper la compatibilidad en espacio de usuario. Y es lógico: de nada sirve el curro de programar un kernel si con una mala decisión rompes de un plumazo la compatibilidad con los programas que lo usan.
Pues no sé, a mi me mosquearía que me contestasen a un error mío de programación con un "Cierra la puta boca", y eso que a mi me pagan. Cuanta justificación veo...
#44 Pero tu seguramente no estás trabajando en un proyecto de semejantes dimensiones y del que depende el funcionamiento de miles de millones de ordenadores. Cuando tienes algo así entre manos tienes que andarte con pies de plomo para no romper nada porque si nadie se entera puede llegar a ser catastrófico, y es por eso precisamente por lo que Linus tiene ir repartiendo collejas a diestro y siniestro.
#46 Hombre, en algo como Linux, no. Pero si he trabajado en proyectos bastante sensibles, y cuando ha habido cagadas ha habido buenas broncas, pero nadie me ha mandado de malas maneras callarme la puta boca.
#51 Pues imagino que no, pero tampoco me imagino insistiendo con un error en mi curro y que en vez de hacérmelo ver, con más o menos paciencia, me manden a la mierda. No me parece correcto.
#55 Si te fijas tampoco se trata de un simple error, es un problema de concepto que a esas alturas puede ser bastante grande, y si le sumas el intentar resbalarlo se complica más. A lo mejor no es buen ejemplo, pero hace poco había un meneo de un puente colgante que acumulaba hielo para luego caer sobre los coches como bombas. El que diseño ese puente es un imbécil, y ojala alguien se lo hubiera dicho con la misma rotundidad en su momento. Por qué? Pues porque eso es un facto que normalmente sí que se tiene en cuenta al construir prácticamente cualquier cosa.
En fin, no pretendo justificar las malas maneras, que en este caso leyendo toda la discusión no me parece tal cosa. Me parece más un golpe sobre la mesa para cerrar una discusión sin fundamento. Si a ti un jefe te dice que hagas algo de una manera, seguramente le harás caso, y es obvio que nunca llegarías a ese termino.
A veces sí hay que hablar sin pelos en la lengua, sobre todo si es algo importante.
#44 Si te fijas, por la respuesta que da Linus y las frases de Mauro, no es que este le enviara un mensaje y aquel se haya subido por las paredes. Más bien es que Mauro ya lo tiene hasta las pelotas de tirar balones fuera y por eso comienza con un cállate de una puta vez. Vamos, que si al principio de la conversación Mauro se hubiera bajado de la burra (y, a pesar de que ni de lejos tengo nivel para discutirle las directrices de desarrollo a ninguno de los dos, estoy de acuerdo con Linus en que no hay que echar balones fuera cuando la cagas), Linus no se hubiera puesto [tan] borde.
Si vierais las broncas que echa de vez en cuando mi jefe... la vena del cuello parece que le va a reventar.
La verdad es que no sé el papel que tiene hoy en día Linus, pero como dicen en los comentarios la gente asocia Linux a Linus (obviamente) por lo tanto para lo bueno y para lo malo es el que da la cara y eso conlleva mucha presión.
Dictador benevolente dice el articulo... es como si Torvalds fuese Pedro el Grande, es decir, vengo y modernizo el nivel de vida de los aldeanos, les ordeno ser felices o que se atengan a las consecuencias...
bromas aparte, habra quien use estas cosas para descalificar la comunidad OSS (si Professor hable de ti y tus secuaces), pero ni modo Torvalds es tan humano como Stallman, o el mismisimo Sir Henry William Gates III ( en serio ese es su nombre completo y el titulo que le dio la reina de inglaterra)
Anda que no me han echado bronca a mí por liarla en el código... Pero como en cualquier trabajo, joder. Esto no debería de ser noticia. De hecho no me imagino al líder de un proyecto tan grande como Linux siendo un buenazo.
El tema de los GOTO creo que lo machacan sobretodo por qué una aplicación llena de GOTO es un infierno para el siguiente (y hasta para ti después de una semana) que le toque repasar el código. Pero si te toca programar un kernel es que eres ya un verdadero crack y cualquier optimización que puedas hacer pesa más aunque te acabe quedando un código infumable.
#23 "f course, in stupid languages like Pascal, where labels cannot be
descriptive, goto's can be bad. But that's not the fault of the goto, that's the braindamage of the language designer."
Joder, pone a caldo a to dios jajajja, como me gustaría conocer al linus trollvarlds
Coño, mando a que jodieran a toda una compañia como Nvidia no va a hacerlo con el bueno de Mauro
#22 son los juankers malvados que se estan cebando con meneame...Eso y la cupula de anonymous, la cupula de anonymous no puede faltar nunca
por cierto, apoyo que hables con tus diversas personalidades multiples en publico #22 #24#28
Independientemente de quien sea, la respuesta es la misma que habría dado cualquier gilipollas de a pie, vulgar y sin clase. Le podria haber dicho al desarrollador que su comentario no tenia fundamento y que deberia in-formarse mejor.
Comentarios
Si se hubieran pegado cuatro voces a algún otro proyecto que yo me se probablemente Linux ahora mismo sería relevante en el escritorio...
#1 No creo que la relevancia de los proyectos en el entorno de Linux dependa de rapapolvos. ¿A caso crees que la relevancia que tiene Linux en cuanto al sector profesional y más concretamente en servidores la tiene, por ejemplo, Microsoft? Creo que es más una cuestión de filosofía de trabajo para cada cosa. Los proyectos open source tienen una metodología y los de software cerrado en ocasiones otra.
#2 No creo que se trate de eso, pero a veces hay que dejar ciertas cosas claras. Es mejor leer la respuesta completa, y sí, es una bronca, pero después de leerlo es una bronca merecida. No tiene sentido que mañana windows saque una actualización y dejen de funcionar programas a causa de ello (sobre todo si están muy extendidos), y luego alguien diga: "No, si es que lo que tiene fallos son los otros programas".
#42 Realmente creo que esa es la parte más ofensiva, lo demás es una crítica muy razonada con alguna ofensa insertada por ahí.
#1 A los que complicaron el GNOME de Ubuntu, ¡golpe de remo!
#11 #13 #15 Hay quien opina que los gotos son aceptables en contadas ocasiones. No olvidemos tampoco que C es considerado, a día de hoy, un lenguaje de medio/bajo nivel.
(Por cierto, 11, acabo de fijarme en tu avatar )
#18 hay que gente que esta muy contenta con el cambio.
lee los comentarios de Gnome volverá a ser el escritorio por defecto en Debian 7 Wheezy
Gnome volverá a ser el escritorio por defecto en D...
lamiradadelreplicante.comEs un proyecto. Las cosas deben hacerse bien.
Linus no debía estar ocupándose de enseñar las bases a los desarrolladores, eso ya lo debían traer aprendido.
Pues quizás las formas le pierden , pero no debe faltar razón a Linus, si encima de un error lo ha intentado arreglar con una parche de mierda (según sus palabras).
#6, pues la verdad es que sí, el arreglo era una mierda hecha con desgana...
The whole patch is incredibly broken shit. It adds an
insane error code (ENOENT), and then because it's so insane, it adds a
few places to fix it up ("ret == -ENOENT ? -EINVAL : ret").
En lugar de corregir el error, lo "rodeó" con un if en los returns.....
Esto ocurre a diario, no es relevante.
#3 pues vota en consecuencia
Seguramente su buzón esté lleno de estupideces y al final sus correos terminen siendo «fucks» por todos los lados, y debe de ser molesto que alguien que se entiende es un profesional en el mantenimiento del kernel cuestione o diga ciertas cosas, porque al fin y al cabo entorpece tu propio trabajo.
Independientemente de su estilo personal, me parece importantísimo que en un proyecto tan grande (en complejidad, y en número de desarrolladores) como el kernel de Linux, haya una figura que sea capaz de cantarle las cuarenta a los colaboradores de cierto rango cuando la cagan.
Si no, pasa lo que en otras meritocracias, que al final el proyecto se va a la mierda por culpa de ciertas malas decisiones tomadas por gente "intocable", las cuales hay que aceptar por el mero hecho de que las ha tomado quien las ha tomado. Y eso mata un proyecto tanto técnicamente, como en el plano personal (la motivación de los programadores "junior" por los suelos).
Además, no es lo más educado del mundo, pero consigue lo que (supongo) persigue, que es el efecto contundencia y que se le quite la chulería al listo de turno. Y si no, mirad su email previo a ver qué humillos tenía el tal Mauro.
Desgraciadamente, el mundo de la informática está repleto de tipos prepotentes, agresivos y maleducados. Eso y las horas extras, hacen que nuestra profesión, que podría ser mucho más apasionante, sea a veces tan desagradable.
#17 si piensas que eso es propio de la informática, estás muy equivocado.
Odio las noticias de ingeniería informática, programación y demás fanfarria. No me entero de un carajo
Eso sí, la discusión sobre el comando goto deja ver que la informática es claramente una ingeniería más, de un nivel diferente al que los de estructuras, electricidad, genética, etc, pero ingeniería al fin y al cabo.
ctrl = uvc_find_control(chain, v4l2_ctrl->id, &mapping);
if (ctrl == NULL)
A mi lo que me flipa es que usen GOTO en el kernel, después de todo lo que me han machacado con que es una mala práctica ... (Lógicamente estará justificado).
#11
No estaría yo tan seguro de que esté debidamente justificado.
#13 #15 Pues yo creo que está justificado, pues como dice #16, hablamos del código de un Kernel y no de una aplicación. Esto implica que debe estar mucho mejor optimizado, y además "sólo" usan una etiqueta (done), con lo que tampoco será tan difícil de mantener...
Lógicamente nos machacan tanto porque en general no se debe usar, pero como en todo, hay excepciones y estas están justificadas.
#16 de hecho importa mucho creo yo. Si trabajan a bajo nivel, trabajan a bajo nivel. Lo hacen por una buena causa al fin y al cabo. Si estuvieran locos, programarían la totalidad del kernel en asm.
#13 el código, una vez compilado, no deja de tener cienmil gotos por todas partes (bueno goto no realmente, pero una clausula que se comporta de la misma forma)
Estos pavos quieren programar lo más parecido al lenguaje máquina posible. Tienen un coco muy desarrollado para la causa y buscan ahorrar el tiempo de ejecución al máximo.
#11 Creo que un goto no es admisible hoy en día en ningún código, ni tan solo por razones de optimización (hay otras formas de conseguir lo mismo...)
#11 Te lo han machacado todo lo que quieras, y por una buena razón: escribir código lleno de GOTO lo convierte en inmantenible.
Pero, ¿sabes una cosa? A la hora de la verdad... cuando acaba todo compilado, enlazado y listo en código ejecutable... ¡está lleno de GOTO! Los JMP de ensamblador, no son otra cosa que GOTO. Todo lo que escribes de forma ordenada y bonita en tu lenguaje preferido (u odiado), acaba convertido en un amasijo infernal de GOTO por todos lados.
El motivo para usarlos en el kernel, es simple: ahorran una mierda de tiempo de ejecución, pero la ahorran millones de veces. Y eso, en el kernel, importa (aunque tampoco sin pasarse, claro).
#16 Hostia, tú eres 1 de los 2 "cracks" que votaron negativo a este:
Un vistazo al robots.txt de la SGAE
Un vistazo al robots.txt de la SGAE
twitter.compor no saber de qué iba la noticia. ¿Ves cómo es muy fácil dar una explicación sin votar negativo?
#11 Haz una búsqueda rápida y verás que el kernel de linux está lleno de gotos. Los usan normalmente como punto de salida de funciones cuando una función tiene varios puntos de salida y hay que hacer algún trabajo de "limpieza" antes de salir. En lugar de copiar el mismo trabajo en cada punto de salida, lo ponen en un solo punto y saltan a él con goto donde hace falta.
#11 A mí lo que me flipa es que siga existiendo gente que piensa que determinadas posibilidades de un lenguaje no se deben usar por que no y punto (y luego les ves haciendo aberraciones peores, como acceder a una dirección de memoria no válida por no usar un break y decir que como no la modifican no pasa nada ). Yo no he usado un goto en la vida, pero un goto end o similar es perfectamente claro y simple, se hace rápido y evita cosas más complicadas y menos eficientes, por ejemplo.
#33 Totalmente de acuerdo.
#11 Pasa una cosa, y es que muchas veces en el kernel hay flujos de ejecución bastante engorrosos de tratar si se utilizan if-else a rajatabla, que encima deterioran el rendimiento si no se utilizan adecuadamente (fíjate que existen hasta macros para optimizar saltos a nivel de núcleo: likely() y unlikely()).
http://www.kernel.org/doc/Documentation/CodingStyle -> Chapter 7
http://stackoverflow.com/questions/109710/likely-unlikely-macros-in-the-linux-kernel -> 1ª respuesta
Es un uso muy puntual y tiene su razón de ser, pero lo suyo es no utilizar gotos jamás, y en el núcleo (como normal general), solo si la alternativa es una penalización al rendimiento.
#11 Sé que mi respuesta es redundante, pero en resumidas cuentas, el problema es que se tiende a usar mal. Usarlo sólo porque existe es una idiotez. Usarlo porque has estudiado los pros y los contras es ingeniería.
#11, las normas existen para saltárselas cuando van contra su propio espíritu. Eso es algo que deberían aprender los jueces.
#11 El problema con el goto es el abuso, no el uso. No tienes que seguir las reglas a rajatabla, puedes tomarte una licencia si lo ves justificado.
Hablo de debida justificación porque en el propio kernel no suele haber muchos bucles que digamos, todo son llamadas a sistema que acceden a dispositivos. El planificador y gestores de memoria es de lo poco que puede tener varios bucles. Si está lleno de gotos estás metiendo saltos incondicionales por un tubo, además de los propios de la función. Eso ya sin entrar en el código espagueti que puede crearse.
Está claro también que te ahorras llamar a una función común por lo que evitas pasos de parámetros de forma continuada, todos sabemos que en el kernel hay que perder el mínimo tiempo posible ya que son las aplicaciones de espacio de usuario las que deben usar la CPU, no el núcleo del sistema operativo. Por ello también las aplicaciones de espacio de usuario no deben abusar de las llamadas a sistema por lo costoso de los cambios de contexto.
Menos rapapolvos y más r@p@p@lv@s.
que, por esto lo dicen?
Lo que digo siempre en estos hilos: me encantan los flames de Linus.
Y no solo por la trolleada y tal, sino más bien por todo lo que aprendo. Y eso que trata de algo que no creo que sea capaz de hacer nunca, como es la programación a "bajo nivel".
El tema de este hilo ya lo he visto en otras discusiones: la primera regla del club del kernel es no romper la compatibilidad en espacio de usuario. Y es lógico: de nada sirve el curro de programar un kernel si con una mala decisión rompes de un plumazo la compatibilidad con los programas que lo usan.
Pues no sé, a mi me mosquearía que me contestasen a un error mío de programación con un "Cierra la puta boca", y eso que a mi me pagan. Cuanta justificación veo...
#44 Pero tu seguramente no estás trabajando en un proyecto de semejantes dimensiones y del que depende el funcionamiento de miles de millones de ordenadores. Cuando tienes algo así entre manos tienes que andarte con pies de plomo para no romper nada porque si nadie se entera puede llegar a ser catastrófico, y es por eso precisamente por lo que Linus tiene ir repartiendo collejas a diestro y siniestro.
#46 Hombre, en algo como Linux, no. Pero si he trabajado en proyectos bastante sensibles, y cuando ha habido cagadas ha habido buenas broncas, pero nadie me ha mandado de malas maneras callarme la puta boca.
#51 Pues imagino que no, pero tampoco me imagino insistiendo con un error en mi curro y que en vez de hacérmelo ver, con más o menos paciencia, me manden a la mierda. No me parece correcto.
#55 Si te fijas tampoco se trata de un simple error, es un problema de concepto que a esas alturas puede ser bastante grande, y si le sumas el intentar resbalarlo se complica más. A lo mejor no es buen ejemplo, pero hace poco había un meneo de un puente colgante que acumulaba hielo para luego caer sobre los coches como bombas. El que diseño ese puente es un imbécil, y ojala alguien se lo hubiera dicho con la misma rotundidad en su momento. Por qué? Pues porque eso es un facto que normalmente sí que se tiene en cuenta al construir prácticamente cualquier cosa.
En fin, no pretendo justificar las malas maneras, que en este caso leyendo toda la discusión no me parece tal cosa. Me parece más un golpe sobre la mesa para cerrar una discusión sin fundamento. Si a ti un jefe te dice que hagas algo de una manera, seguramente le harás caso, y es obvio que nunca llegarías a ese termino.
A veces sí hay que hablar sin pelos en la lengua, sobre todo si es algo importante.
#44 Si te fijas, por la respuesta que da Linus y las frases de Mauro, no es que este le enviara un mensaje y aquel se haya subido por las paredes. Más bien es que Mauro ya lo tiene hasta las pelotas de tirar balones fuera y por eso comienza con un cállate de una puta vez. Vamos, que si al principio de la conversación Mauro se hubiera bajado de la burra (y, a pesar de que ni de lejos tengo nivel para discutirle las directrices de desarrollo a ninguno de los dos, estoy de acuerdo con Linus en que no hay que echar balones fuera cuando la cagas), Linus no se hubiera puesto [tan] borde.
Lo que en Menéame se viene llamando un fascista, vamos.
Torvals genio: sí
Torvalds grosero: también
Si vierais las broncas que echa de vez en cuando mi jefe... la vena del cuello parece que le va a reventar.
La verdad es que no sé el papel que tiene hoy en día Linus, pero como dicen en los comentarios la gente asocia Linux a Linus (obviamente) por lo tanto para lo bueno y para lo malo es el que da la cara y eso conlleva mucha presión.
Se puede discutir las formas pero el fondo. Alguien se pensó que el software libre era una broma.
Linus Torv@lds...
#34 Linus Trollvalds.
Dictador benevolente dice el articulo... es como si Torvalds fuese Pedro el Grande, es decir, vengo y modernizo el nivel de vida de los aldeanos, les ordeno ser felices o que se atengan a las consecuencias...
bromas aparte, habra quien use estas cosas para descalificar la comunidad OSS (si Professor hable de ti y tus secuaces), pero ni modo Torvalds es tan humano como Stallman, o el mismisimo Sir Henry William Gates III ( en serio ese es su nombre completo y el titulo que le dio la reina de inglaterra)
#10 Es un título humorístico para los creadores de proyectos de código abierto
http://es.wikipedia.org/wiki/Benevolent_Dictator_for_Life
Menuda mierda de rapapolvo. Linus Torvalds es como Carlito Brigante: no es que haya cambiado, es que ha perdido fuerza con el tiempo.
Esta bronca es educada y razonada comparada con algunas antiguas de Mr. Torvalds.
El Mauro ese de Red Hat es un echamierdista escaqueator como la copa de un pino con los cojones cuadraos
La bronca se la ha echado por una cosa que es FUNDAMENTAL en el desarrollo colaborativo: hay que hacer las cosas con cariño.
66
El tema es que se utilizan por rendimiento ya que si se encapsulasen en funciones sería mucho más manejable.
Anda que no me han echado bronca a mí por liarla en el código... Pero como en cualquier trabajo, joder. Esto no debería de ser noticia. De hecho no me imagino al líder de un proyecto tan grande como Linux siendo un buenazo.
Como se las gasta el Torvald
#5 a mi me parece demasiado benévolo con el interfecto
#7 Cierto. Deberías ver la que le cayó al insensato que se atrevió a insinuar que git debería haberse escrito en C++: http://harmful.cat-v.org/software/c++/linus
La primera línea es:
*YOU* are full of bullshit.
Y después va a peor.
a esos niveles no entiendo mucho, lo que sea pero que lo arreglen que luego nos pilla el programita de marras en un bucle y nos volvemos locos...
Me hace gracia lo sorprendido y medio indignado que se muestra el redactor de genbetadev... ains
¿Me pasa sólo a mí lo de que aparezcan muchas de las palabras escritas con @ o con x para distinguir las palabras de género?
El tema de los GOTO creo que lo machacan sobretodo por qué una aplicación llena de GOTO es un infierno para el siguiente (y hasta para ti después de una semana) que le toque repasar el código. Pero si te toca programar un kernel es que eres ya un verdadero crack y cualquier optimización que puedas hacer pesa más aunque te acabe quedando un código infumable.
#22 Mira el calendario
#23 "f course, in stupid languages like Pascal, where labels cannot be
descriptive, goto's can be bad. But that's not the fault of the goto,
that's the braindamage of the language designer."
Joder, pone a caldo a to dios jajajja, como me gustaría conocer al linus trollvarlds
#23 Las explicaciones y casos de uso que dan me parecen muy interesantes independientemente del rendimiento.
#22 Por ejemplo: el titular de la noticia que va antes de esta me aparece así : "L@ falt@ de pasajer@s aconseja el cierre de 15 aeropuert@s españoles"
Coño, mando a que jodieran a toda una compañia como Nvidia no va a hacerlo con el bueno de Mauro
#22 son los juankers malvados que se estan cebando con meneame...Eso y la cupula de anonymous, la cupula de anonymous no puede faltar nunca
por cierto, apoyo que hables con tus diversas personalidades multiples en publico #22 #24 #28
#22 El dí@ de l@s in@centes
Perdón. Que demonios es esto???
Edito: Vale, acabo de ller a #25, estaba acojonao.
#29 Si tuviera que adivinar diria que es una captura de pantalla hecha desde un ipad con la portada de meneame abierta
#30 ZAS! Por un momento pensé que se me había jodido.
#29 Jodido nuevo iPad, tiene más resolución que mi pantalla de 19" Aunque por lo que veo sigue con el mismo navegador mierder del primero.
#22 anda coño! Si es que nomentero! Gracias
Fanboys everywhere!
Independientemente de quien sea, la respuesta es la misma que habría dado cualquier gilipollas de a pie, vulgar y sin clase. Le podria haber dicho al desarrollador que su comentario no tenia fundamento y que deberia in-formarse mejor.