#4:
#2 Hace más de 6 años que Alan Cox dejó ese puesto a andrew morton, y estuvo un par de años completamente al margen porque se puso a hacer un MBA....a día de hoy alan cox mantiene cosas variadas a su gusto: algunas cosas de libata, serial, tty...los maintainers siempre vienen y van, ya sea por casos como este, o porque se aburren. Cuando dejan una cosa, no es raro que se metan en otro. Como digo, esto está teniendo una extraña repercusión en todos los sitios de noticias, mientras que en la lista del kernel no es más que el flamewar de todas las semanas.
#2:
#1 Alan Cox es el segundo hombre mas importante en desarrollo de linux despues del propio Torvalds.
Y personalmente tengo que estar de acuerdo con Linus, no pueden romper las APIs que exportan al espacio de usuario. La gente no va aceptar que sobre el kernel 2.6.31 varías aplicaciones dejasen de funcionar.
De hecho el tema de la conversación lo deja claro [PATCH] kdesu broken, como usuario de kde no me dejan otra opción que apoyar a Linus. Imaginaros que el Flash de Adobe u otro software privativo también estuviera afectado, porque kdesu es libre y se puede recompilar y parchear, pero el Flash no.
PD: Y no se hasta que punto esto tiene que ver con que ahora trabaja para intel http://lwn.net/Articles/312631/ antes trabajaba para Red Hat. Aunque vaya a seguir desarrollando linux, intel tiene otros intereses.
#3:
#2 Tiene razón, este señor no es cualquiera. Ya no hablo siquiera de sus conocimientos o su trabajo en el kernel actual, si no de quien ha sido en la historia de linux.
#2 Hace más de 6 años que Alan Cox dejó ese puesto a andrew morton, y estuvo un par de años completamente al margen porque se puso a hacer un MBA....a día de hoy alan cox mantiene cosas variadas a su gusto: algunas cosas de libata, serial, tty...los maintainers siempre vienen y van, ya sea por casos como este, o porque se aburren. Cuando dejan una cosa, no es raro que se metan en otro. Como digo, esto está teniendo una extraña repercusión en todos los sitios de noticias, mientras que en la lista del kernel no es más que el flamewar de todas las semanas.
#11 No se marcha, ha dimitido como mantenedor de TTY, pero sigue como desarrollador este mensaje es del día siguiente http://lkml.org/lkml/2009/7/28/606
Y personalmente tengo que estar de acuerdo con Linus, no pueden romper las APIs que exportan al espacio de usuario. La gente no va aceptar que sobre el kernel 2.6.31 varías aplicaciones dejasen de funcionar.
De hecho el tema de la conversación lo deja claro [PATCH] kdesu broken, como usuario de kde no me dejan otra opción que apoyar a Linus. Imaginaros que el Flash de Adobe u otro software privativo también estuviera afectado, porque kdesu es libre y se puede recompilar y parchear, pero el Flash no.
PD: Y no se hasta que punto esto tiene que ver con que ahora trabaja para intel http://lwn.net/Articles/312631/ antes trabajaba para Red Hat. Aunque vaya a seguir desarrollando linux, intel tiene otros intereses.
#2 Tiene razón, este señor no es cualquiera. Ya no hablo siquiera de sus conocimientos o su trabajo en el kernel actual, si no de quien ha sido en la historia de linux.
Nooo, Alan Cox no. Esto significa que me estoy haciendo viejo. Cuando hacía informática venerábamos a Alan Cox y nos partíamos el culo con sus frases míticas y un documental en el que salía en una habitación oscura diciendo que el código era poesía para él. Y ahora se marcha.
Por otra parte, en serio, Linus tiene que dejar de escribir esos expresivo mensajes con cosas como Your code is bullshit, You are a moron, You are crazy. A lo mejor debería mirar algo de relaciones públicas.
Echando un cable a un estudiante de teleco este año nos curramos a medias un módulo del kernel que se metía de lleno en el subsistema TTY para hacer un par de cosas sobre el puerto serie. Toda esa movida de tty->ldisc es mucho más entretenida de lo que parece.
Con mucho, TTY es la peor parte del kernel Linux. De hecho, en mi opinión, es un montón de mierda humeante que debería replantearse desde cero. Y si emacs depende de comportamiento no definido y casca con ENOENT, pues que lo arregle Stallman. Con ext4 pasó lo mismo: En ext3 se hacían commits cada 5 segundos. Cuando introdujeron la asignación retrasada de espacio en ext4 medio kde cascó porque dependía de un comportamiento no definido, el commit cada 5 segundos no pertenecía a la api, ni a posix, y podían haber usado fsync/fdatasync. No entraba en el contrato entre el desarrollador del kernel y el espacio de usuario.
La próxima vez que cambiemos una pieza por otra en el kernel y el espacio de usuario falle porque depende de comportamiento indefinido ¿Qué haremos? ¿Parcheamos el espacio de usuario o parcheamos el kernel? Creo que la solución con más mérito técnico ha dejado de ser la que cuenta en Linux. Hay demasiado politiqueo.
Aun sigo preguntándome por qué se le está dando tanta relevancia a esto...maintainers que se salen porque están desacuerdo con alguien se ven a menudo. Hace dos semanas o así dejó el puesto el de IDE tras una discusión con el de SPARC, por ejemplo.
el susodicho Alan siempre a tenido un look impactante, se había moderado poco a poco. Antes las instalaciones de redhat tenían una imagen de el y poco a poco fue recortándose el pelo y la barba. Pero según la imagen que acompaña a la noticia en alcance libre, parece que ha vuelto a desmelenarse, look estilo zztop, o .. ¿Gnome?. http://www.alcancelibre.org/images/articles/alancox-renuncia-mantener-subsistema-tty_1.jpg
Por lo mayor que está imagino que es reciente, el tiempo pasa para todos.
Despues de leer la trifulca echo en menos un tercer mail de uno de los muchos fanboys que tenemos por aquí, diciendoles a ambos que en su Ubuntu eso no pasa.
#16 Esa dureza en los comentarios es marca de la casa de Linus, pero no es nada comparado con los comentarios de Al Viro (al loro, una autoridad en el kernel al mismo nivel que Morton y compañía).
Este es su comentario hablando de Subversion, en una época en la que existía la polémica con Bitkeeper y la posibilidad de substituirlo por otro software de control de versiones:
#16 Alan Cox tampoco es que se corte mucho: "Get real, that is what you just claimed and its donkey poo."
La verdad es que estoy con #4. Es normal que con el tiempo la gente se canse de un proyecto y se vaya a hacer otro. En estos casos, Linus consigue agilizar bastante el proceso llamando las cosas por su nombre: si no le gusta el código, lo dice sin rodeos. Luego si a alguien le sienta mal, solo significa que no tiene ganas de esforzarse por arreglarlo, con lo que es mejor -para él y para todos- que haga otra cosa, algo que le guste más.
#30 si emacs, o kdesu, o los lockfiles de kde están mal programados, que sus desarrolladores los arreglen. En el kernel no tienen culpa de que se aprovechen de ciertos detalles de implementación que no tienen porque mantenerse en el tiempo. Es exactamente la misma razón por la que Linux no tiene una ABI: el kernel va cambiando con el tiempo. Uno puede contar con que las syscall se mantengan igual de versión en versión. Sólo las syscall.
De lo contrario, lo que les estamos diciendo a los desarrolladores del kernel es que no modifiquen nada nunca más.
Linux no tiene una ABI estable para los modulos del kernel y APIs exclusivas de modo núcleo. Para el espacio de usuario si se tiene una API y ABI estable.
Sobre el tema de fsync ya se hablo unas frases destacadas de Linus
Anybody who wants more complex and subtle filesystem interfaces is just crazy.
The undeniable FACT that people don't tend to check errors from close()
should, for example, mean that delayed allocation must still track disk
full conditions, for example. If your filesystem returns ENOSPC at close()
rather than at write(), you just lost error coverage for disk full cases
from 90% of all apps. It's that simple.
Crying that it's an application bug is like crying over the speed of
light: you should deal with reality, not what you wish reality was. Same
goes for any complaints that "people should write a temp-file, fsync it,
and rename it over the original". You may wish that was what they did, but
reality is that "open(filename, O_TRUNC | O_CREAT, 0666)" thing.
Harsh, I know. And in the end, even the good applications will decide
that it's not worth the performance penalty of doing an fsync(). In git,
for example, where we generally try to be very very very careful,
'fsync()' on the object files is turned off by default.
Theory and practice sometimes clash. And when that happens, theory loses.
Every single time.
#28 ¿Qué politequeo? Pues... ¿no están diciendo precisamente por ahí arriba que lo que se procura es que no se rompa la compatibilidad con las aplicaciones existentes hasta el momento -lo cual es crítico en el software propietario/privativo usado en Linux?
esto va en plan cachondeo, pero os digo y me apuesto mi dedo indice derecho mi cuenta de facebook y twitter (a mas no me atrevo) a que el 70% de los que nos paseamos por la portada de meneame no entendemos la mitad de esta noticia jeje (y no por lo del S L )
Ese es el problema #4, que es el flamewar de cada semana. Si no se aprecia a personas que han contribuido durante tanto tiempo al desarrollo de linux ¿Qué puede esperar un recién llegado?
La verdad que da la impresión de que Linus debe ser un tío difícil de tratar. Debe ser bastante prepotente y debe habérsele subido la fama a la cabeza.
Parece algo común en el mundo de la informática, en cuanto uno es un poco bueno en lo suyo y destaca, se le acaban subiendo los humos. Lo malo es cuando este tipo de cosas perjudican a la comunidad como en este caso
Comentarios
#2 Hace más de 6 años que Alan Cox dejó ese puesto a andrew morton, y estuvo un par de años completamente al margen porque se puso a hacer un MBA....a día de hoy alan cox mantiene cosas variadas a su gusto: algunas cosas de libata, serial, tty...los maintainers siempre vienen y van, ya sea por casos como este, o porque se aburren. Cuando dejan una cosa, no es raro que se metan en otro. Como digo, esto está teniendo una extraña repercusión en todos los sitios de noticias, mientras que en la lista del kernel no es más que el flamewar de todas las semanas.
#1 Alan Cox es el segundo hombre mas importante en desarrollo de linux despues del propio Torvalds.
#11 No se marcha, ha dimitido como mantenedor de TTY, pero sigue como desarrollador este mensaje es del día siguiente http://lkml.org/lkml/2009/7/28/606
Y personalmente tengo que estar de acuerdo con Linus, no pueden romper las APIs que exportan al espacio de usuario. La gente no va aceptar que sobre el kernel 2.6.31 varías aplicaciones dejasen de funcionar.
De hecho el tema de la conversación lo deja claro [PATCH] kdesu broken, como usuario de kde no me dejan otra opción que apoyar a Linus. Imaginaros que el Flash de Adobe u otro software privativo también estuviera afectado, porque kdesu es libre y se puede recompilar y parchear, pero el Flash no.
PD: Y no se hasta que punto esto tiene que ver con que ahora trabaja para intel http://lwn.net/Articles/312631/ antes trabajaba para Red Hat. Aunque vaya a seguir desarrollando linux, intel tiene otros intereses.
#2 Tiene razón, este señor no es cualquiera. Ya no hablo siquiera de sus conocimientos o su trabajo en el kernel actual, si no de quien ha sido en la historia de linux.
Nooo, Alan Cox no. Esto significa que me estoy haciendo viejo. Cuando hacía informática venerábamos a Alan Cox y nos partíamos el culo con sus frases míticas y un documental en el que salía en una habitación oscura diciendo que el código era poesía para él. Y ahora se marcha.
#15 Uno de los desarrolladores más importantes de Linux, lleva desde las primeras versiones de desarrollo de 1991. Empleado de Red Hat durante 10 años y recientemente contratado por intel http://lwn.net/Articles/312631/ http://es.wikipedia.org/wiki/Alan_Cox
Y si preguntas que es TTY estás baneado, estos papeles son de IBM AIX, pero vienen a ser lo mismo http://publib.boulder.ibm.com/infocenter/systems/topic/com.ibm.aix.genprogc/doc/genprogc/ttysys.htm
Por otra parte, en serio, Linus tiene que dejar de escribir esos expresivo mensajes con cosas como Your code is bullshit, You are a moron, You are crazy. A lo mejor debería mirar algo de relaciones públicas.
Echando un cable a un estudiante de teleco este año nos curramos a medias un módulo del kernel que se metía de lleno en el subsistema TTY para hacer un par de cosas sobre el puerto serie. Toda esa movida de tty->ldisc es mucho más entretenida de lo que parece.
Con mucho, TTY es la peor parte del kernel Linux. De hecho, en mi opinión, es un montón de mierda humeante que debería replantearse desde cero. Y si emacs depende de comportamiento no definido y casca con ENOENT, pues que lo arregle Stallman. Con ext4 pasó lo mismo: En ext3 se hacían commits cada 5 segundos. Cuando introdujeron la asignación retrasada de espacio en ext4 medio kde cascó porque dependía de un comportamiento no definido, el commit cada 5 segundos no pertenecía a la api, ni a posix, y podían haber usado fsync/fdatasync. No entraba en el contrato entre el desarrollador del kernel y el espacio de usuario.
La próxima vez que cambiemos una pieza por otra en el kernel y el espacio de usuario falle porque depende de comportamiento indefinido ¿Qué haremos? ¿Parcheamos el espacio de usuario o parcheamos el kernel? Creo que la solución con más mérito técnico ha dejado de ser la que cuenta en Linux. Hay demasiado politiqueo.
¿Pierdo mucho karma si pregunto quien es Cox?
Aun sigo preguntándome por qué se le está dando tanta relevancia a esto...maintainers que se salen porque están desacuerdo con alguien se ven a menudo. Hace dos semanas o así dejó el puesto el de IDE tras una discusión con el de SPARC, por ejemplo.
Pero el que se retire como mantenedor del subsistema TTY quiere decir que se retirará completamente del desarrollo del nucleo?
#19 "Código Linux" creo.
, pero mira a ver si lo encuentras en otro sitio porque ese se ve como el culo.Creo que es
#5 Ni de coña, pero el comentario es gracioso
Deberían arreglarlo tomando una cerveza, que está de moda y el calor lo propicia
Alan Cox no es un hacker del kernel cualquiera. Es una pérdida bastante importante.
el susodicho Alan siempre a tenido un look impactante, se había moderado poco a poco. Antes las instalaciones de redhat tenían una imagen de el y poco a poco fue recortándose el pelo y la barba. Pero según la imagen que acompaña a la noticia en alcance libre, parece que ha vuelto a desmelenarse, look estilo zztop, o .. ¿Gnome?.
http://www.alcancelibre.org/images/articles/alancox-renuncia-mantener-subsistema-tty_1.jpg
Por lo mayor que está imagino que es reciente, el tiempo pasa para todos.
Despues de leer la trifulca echo en menos un tercer mail de uno de los muchos fanboys que tenemos por aquí, diciendoles a ambos que en su Ubuntu eso no pasa.
#16 Esa dureza en los comentarios es marca de la casa de Linus, pero no es nada comparado con los comentarios de Al Viro (al loro, una autoridad en el kernel al mismo nivel que Morton y compañía).
Este es su comentario hablando de Subversion, en una época en la que existía la polémica con Bitkeeper y la posibilidad de substituirlo por otro software de control de versiones:
http://lkml.indiana.edu/hypermail/linux/kernel/0210.0/2508.html
#13 parece que Alcance Libre no permite el hotlinking ni siquiera desde dentro de sus propias URL
#26 Ten cuidadín que Linus te hace un kill -9 desde la otra punta del planeta, y sin conexión a internet ni nada
#16 Alan Cox tampoco es que se corte mucho: "Get real, that is what you just claimed and its donkey poo."
La verdad es que estoy con #4. Es normal que con el tiempo la gente se canse de un proyecto y se vaya a hacer otro. En estos casos, Linus consigue agilizar bastante el proceso llamando las cosas por su nombre: si no le gusta el código, lo dice sin rodeos. Luego si a alguien le sienta mal, solo significa que no tiene ganas de esforzarse por arreglarlo, con lo que es mejor -para él y para todos- que haga otra cosa, algo que le guste más.
#31 Gates será el dueño de la empresa, pero como programador.. ni número 1 ni tan siquiera número 1000.
Cagao !! A que no hay güevos a arreglarlo !! ( asi se le pica a la gente en mi pueblo para que haga lo que no quiere hacer en principio );)
#30 si emacs, o kdesu, o los lockfiles de kde están mal programados, que sus desarrolladores los arreglen. En el kernel no tienen culpa de que se aprovechen de ciertos detalles de implementación que no tienen porque mantenerse en el tiempo. Es exactamente la misma razón por la que Linux no tiene una ABI: el kernel va cambiando con el tiempo. Uno puede contar con que las syscall se mantengan igual de versión en versión. Sólo las syscall.
De lo contrario, lo que les estamos diciendo a los desarrolladores del kernel es que no modifiquen nada nunca más.
Linux no tiene una ABI estable para los modulos del kernel y APIs exclusivas de modo núcleo. Para el espacio de usuario si se tiene una API y ABI estable.
#37 No va a romper las APIs de espacio de usuario ni va a haber un Linux 3.0 http://apcmag.com/linus_torvalds_talks_future_of_linux.htm
Sobre el tema de fsync ya se hablo unas frases destacadas de Linus
Anybody who wants more complex and subtle filesystem interfaces is just crazy.
The undeniable FACT that people don't tend to check errors from close()
should, for example, mean that delayed allocation must still track disk
full conditions, for example. If your filesystem returns ENOSPC at close()
rather than at write(), you just lost error coverage for disk full cases
from 90% of all apps. It's that simple.
Crying that it's an application bug is like crying over the speed of
light: you should deal with reality, not what you wish reality was. Same
goes for any complaints that "people should write a temp-file, fsync it,
and rename it over the original". You may wish that was what they did, but
reality is that "open(filename, O_TRUNC | O_CREAT, 0666)" thing.
Harsh, I know. And in the end, even the good applications will decide
that it's not worth the performance penalty of doing an fsync(). In git,
for example, where we generally try to be very very very careful,
'fsync()' on the object files is turned off by default.
Theory and practice sometimes clash. And when that happens, theory loses.
Every single time.
http://lkml.org/lkml/2009/3/25/632
PS: Yo sería partidario de aceptar un puñado de rupturas cada 10 años avisando con años de antelación, pero eso no es cosa mía.
#11, ¿cómo se llama ese documental? Lo vi en Arte hace un par de años o así y me gustaría volver a verlo.
Gracias, #20
#5 ¿No será más bien Linus?. Primero dice que si el odio a Microsoft es una enfermedad, ahora discute con uno de los pilares fundamentales del Kernel... no sé, no sé...
"El odio hacia Microsoft es una enfermedad" Linus Torvalds
"El odio hacia Microsoft es una enfermedad&qu...
osnews.com(bis BP)
#12 gracias, me quitas 5 años de encima
Alan Cox es el que hizo de Watson en el secreto de la pirámide ¿no? Vamos, el hijo de Brian Cox...
#28 ¿Qué politequeo? Pues... ¿no están diciendo precisamente por ahí arriba que lo que se procura es que no se rompa la compatibilidad con las aplicaciones existentes hasta el momento -lo cual es crítico en el software propietario/privativo usado en Linux?
#24 Pues la imagen de Alcance libre es la que aparece en la wikipedia. ¿Curioso, no?.
esto va en plan cachondeo, pero os digo y me apuesto mi dedo indice derecho mi cuenta de facebook y twitter (a mas no me atrevo) a que el 70% de los que nos paseamos por la portada de meneame no entendemos la mitad de esta noticia jeje (y no por lo del S L )
Todas estas personas, si no tuviesen un ego tan grande, no harian programas tan grandes. Las dos cosas van unidas.
Ese es el problema #4, que es el flamewar de cada semana. Si no se aprecia a personas que han contribuido durante tanto tiempo al desarrollo de linux ¿Qué puede esperar un recién llegado?
El comentario http://linux.slashdot.org/comments.pl?sid=1319387&cid=28873797 en slashdot es muy buen ejemplo de la actitud "yo la tengo mas grande" que se mantiene en el desarrollo de linux.
Quien quiera escribirle éste es su e-mail:
Alan Cox: anarchy@sunacm.swan.ac.uk
Alan Cox es anarquista.
De Linux se va el número 2 pero de Windows se fue el número 1, Gates, y ya hace un tiempo de esto => Linux siempre va por detrás de Windows.
La verdad que da la impresión de que Linus debe ser un tío difícil de tratar. Debe ser bastante prepotente y debe habérsele subido la fama a la cabeza.
Parece algo común en el mundo de la informática, en cuanto uno es un poco bueno en lo suyo y destaca, se le acaban subiendo los humos. Lo malo es cuando este tipo de cosas perjudican a la comunidad como en este caso
Ésto acerca a Alan Cox a MicroSoft.
Se hunde Linux!