Linus Torvalds no está contento con el autor de systemd Kay Sievers
Los desarrolladores del kernel de Linux y los desarrolladores de systemd se enfrentaron esta semana con respecto a un error en systemd que paraba los sistemas de arranque. El error fue presentado por Borislav Petkov donde explicó que el fallo en systemd no estaba permitiendo que iniciara la sesión en la pc. Kay Sievers, el co-autor de systemd sugirió a los desarrolladores del kernel de no usar el término "depuración" por ser demasiado genérico, "Al igual que para el núcleo, hay opciones para adecuadas para comportamiento en cuanto al control de registro de systemd ; simplemente no utilice el término genérico "debug".
"Linus Torvalds no está contento con el autor systemd Kay Sievers"
Todo se convirtio en un acalorado debate sobre LKML donde Linus regañó, de la forma que lo hace a Kay por no arreglar sus propios problemas.
Linus escribió:
Kay , estoy f * cking cansado con el hecho de que usted no arregle los problemas en el código *su * codigo , por lo que el kernel entonces tiene que trabajar en torno a los problemas que causa su codigo.
Greg - sólo para su información, yo * no * estaría fusionando cualquier código de Kay en el kernel hasta que se corrija.
"Linus Torvalds no está contento con el autor systemd Kay Sievers"
Todo se convirtio en un acalorado debate sobre LKML donde Linus regañó, de la forma que lo hace a Kay por no arreglar sus propios problemas.
Linus escribió:
Kay , estoy f * cking cansado con el hecho de que usted no arregle los problemas en el código *su * codigo , por lo que el kernel entonces tiene que trabajar en torno a los problemas que causa su codigo.
Greg - sólo para su información, yo * no * estaría fusionando cualquier código de Kay en el kernel hasta que se corrija.
Linus:
Esto ha estado sucediendo desde hace * años * , y no parece estar mejorando. Esto es importante para usted, porque he visto que se habla de los parches kdbus , y esto es un mano a mano que usted necesita para mantenerlos separados de otros trabajos. Deje que las distribuciones se fusionen como lo necesitan y quizá podamos fusionar una vez que se ha demostrado ser estable por cualquier distro que estaba dispuesto a jugar con los desarrolladores.
Pero yo no estoy dispuesto a fusionar algo donde se conoce que el mantenedor no se preocupa por los errores y regresiones y luego obliga a la gente en otros proyectos arreglar su proyecto. Porque yo * no * estoy dispuesto a tomar los parches de personas que no limpin después sus problemas , y no admitir que es su problema solucionar.
Kay - una vez más: usted causó el problema , tiene que arreglarlo. Nada de esto " yo puedo hacer lo que quiera , otros tienen que limpiar después de mí" M&//a .
No todo el mundo dentro de la comunidad del núcleo parece estar cómodo con la actitud de los autores sysetmd . Theodore Ts'o de ext4 compartió la discusión LKML en Google+ diciendo: "Para aquellos que creen que los desarrolladores systemd son razonables van escuchar una crítica constructiva ..... "
Entonces Lennart Poettering , otro autor de systemd , no demoró en publicar y responder en Google+ para aclarar las cosas y dijo ( leer todo comentario aquí) ,
Para mí está fuera de cuestión, sin embargo systemd y otros componentes principales del sistema operativo deben seguir para analizar la opción 'debug ' cmdline del kernel, y aumentar sus niveles de depuración entonces.
Opciones genéricas como que se supone que son de utilidad para la gente real , y hay una larga historia de opciones como las que influyen tanto en el núcleo y espacio de usuario ( tranquilo, root = , ...) . Estamos armando un sistema operativo aquí , después de todo , no sólo un núcleo, un núcleo es sólo un componente del sistema operativo entre muchos, y en última instancia, un detalle de implementación.
Estamos escribiendo un sistema operativo aquí con el propósito general, no sólo un juguete para una camarilla de desarrolladores del núcleo . Además , hay opciones de línea de órdenes del núcleo individuales , tanto para el núcleo en sí como systemd controlan sólo sus niveles de registro , y nada más. así que si usted desea tener un control fino, ya lo tienes , 'debug ' es sólo la simple opción que agrupa todos bajo una sola opción oneshot . Es la opción de que un administrador puede especificar qué le dice por qué el sistema no se inicia , independientemente de si el kernel o systemd tiene la culpa o cualquier otra parte del sistema operativo centrales involucrados en el arranque. Eso es simplemente fácil de usar .
Linus respondió al mensaje de Lennart , que fue compartido de Greg KH y dijo :
Ok , así que exactamente cuál era el problema con " systemd.debug " otra vez?
Supongo que esto no significa que tengamos que aplicar mi parche para los mensajes de límite de velocidad en el kernel. Bien, yo no odio ese parche , pero yo los odio por el hecho de que systemd parece pensar " que estamos siendo gilipollas, y no es nuestro problema, los demás deben protegerse contra nuestro f * cked " .
Así que con esto realmente no me dan ganas de trabajar nunca con Kay Sievers , porque todo esto sólo refuerza el hecho de que él no le importa si sus cambios causan dolor a otros proyectos.
En el kernel, tenemos esa regla de "no regresión " por un buen motivo . Por ejemplo , no es una excusa válida para decir "bueno, el espacio de usuario no debería haber hecho eso , para empezar, por lo que ahora podemos romperlo " .
Pero Kay parece pensar que romper otro flujo de trabajo de otras personas está muy bien. Y no se pide disculpas por él, y cierra los informes de error cuando se produce, y rechaza la solución obvia y razonable.
+Greg Kroah- Hartman : Yo realmente esperaba que usted pudiera presionar lo trivial y evidente a través de una one-liner . ¿Qué está pasando aquí ? En su lugar, están difundiendo una m/(&&a sin complejos de Kay.
Linus esta realmente enojado con Kay , cuando dijo: " ¿Te gustaría trabajar con una persona que lo hace muy claro ( una y otra vez ) que no le importa si le causa dolor ? ¿En serio? "
Esto no es nuevo o polémico para los desarrolladores de Linux que tienen acaloradas discusiones sobre los temas . Esta es ' la' gente que construye Linux y las cosas se calientan hasta antes de que se calmen.
Pero yo no estoy dispuesto a fusionar algo donde se conoce que el mantenedor no se preocupa por los errores y regresiones y luego obliga a la gente en otros proyectos arreglar su proyecto. Porque yo * no * estoy dispuesto a tomar los parches de personas que no limpin después sus problemas , y no admitir que es su problema solucionar.
Kay - una vez más: usted causó el problema , tiene que arreglarlo. Nada de esto " yo puedo hacer lo que quiera , otros tienen que limpiar después de mí" M&//a .
No todo el mundo dentro de la comunidad del núcleo parece estar cómodo con la actitud de los autores sysetmd . Theodore Ts'o de ext4 compartió la discusión LKML en Google+ diciendo: "Para aquellos que creen que los desarrolladores systemd son razonables van escuchar una crítica constructiva ..... "
Entonces Lennart Poettering , otro autor de systemd , no demoró en publicar y responder en Google+ para aclarar las cosas y dijo ( leer todo comentario aquí) ,
Para mí está fuera de cuestión, sin embargo systemd y otros componentes principales del sistema operativo deben seguir para analizar la opción 'debug ' cmdline del kernel, y aumentar sus niveles de depuración entonces.
Opciones genéricas como que se supone que son de utilidad para la gente real , y hay una larga historia de opciones como las que influyen tanto en el núcleo y espacio de usuario ( tranquilo, root = , ...) . Estamos armando un sistema operativo aquí , después de todo , no sólo un núcleo, un núcleo es sólo un componente del sistema operativo entre muchos, y en última instancia, un detalle de implementación.
Estamos escribiendo un sistema operativo aquí con el propósito general, no sólo un juguete para una camarilla de desarrolladores del núcleo . Además , hay opciones de línea de órdenes del núcleo individuales , tanto para el núcleo en sí como systemd controlan sólo sus niveles de registro , y nada más. así que si usted desea tener un control fino, ya lo tienes , 'debug ' es sólo la simple opción que agrupa todos bajo una sola opción oneshot . Es la opción de que un administrador puede especificar qué le dice por qué el sistema no se inicia , independientemente de si el kernel o systemd tiene la culpa o cualquier otra parte del sistema operativo centrales involucrados en el arranque. Eso es simplemente fácil de usar .
Linus respondió al mensaje de Lennart , que fue compartido de Greg KH y dijo :
Ok , así que exactamente cuál era el problema con " systemd.debug " otra vez?
Supongo que esto no significa que tengamos que aplicar mi parche para los mensajes de límite de velocidad en el kernel. Bien, yo no odio ese parche , pero yo los odio por el hecho de que systemd parece pensar " que estamos siendo gilipollas, y no es nuestro problema, los demás deben protegerse contra nuestro f * cked " .
Así que con esto realmente no me dan ganas de trabajar nunca con Kay Sievers , porque todo esto sólo refuerza el hecho de que él no le importa si sus cambios causan dolor a otros proyectos.
En el kernel, tenemos esa regla de "no regresión " por un buen motivo . Por ejemplo , no es una excusa válida para decir "bueno, el espacio de usuario no debería haber hecho eso , para empezar, por lo que ahora podemos romperlo " .
Pero Kay parece pensar que romper otro flujo de trabajo de otras personas está muy bien. Y no se pide disculpas por él, y cierra los informes de error cuando se produce, y rechaza la solución obvia y razonable.
+Greg Kroah- Hartman : Yo realmente esperaba que usted pudiera presionar lo trivial y evidente a través de una one-liner . ¿Qué está pasando aquí ? En su lugar, están difundiendo una m/(&&a sin complejos de Kay.
Linus esta realmente enojado con Kay , cuando dijo: " ¿Te gustaría trabajar con una persona que lo hace muy claro ( una y otra vez ) que no le importa si le causa dolor ? ¿En serio? "
Esto no es nuevo o polémico para los desarrolladores de Linux que tienen acaloradas discusiones sobre los temas . Esta es ' la' gente que construye Linux y las cosas se calientan hasta antes de que se calmen.
0 comentarios:
Publicar un comentario
Si comentas te pedimos por favor respeto y críticas constructivas referentes al título del articulo. Cualquier comentario para desviar el tema, spam o trolleo no será permitido. Gracias por comentar.