por
pobrecito hablador
el Miércoles, 03 Diciembre de 2003, 01:02h
(#240769)
Los parches SIEMPRE han estado disponibles y las distribuciones SIEMPRE actualizan cuando hay un fallo de seguridad. Cuando estaba el ptrace, había parche.
Claro. Y si fuera por el kernel oficial nos quedábamos en pelotas. Es decir, estabilidad y versiones menores sí, cambios de VMs también, pero eso no se lleva para bugfixes que tapan agujeros de seguridad del tamaño de un campo de fútbol.
Pudiendo sacar a la luz una release que corrija un agujero como ese, noooo, "a nosotros eso nos da igual" se deben decir, que las distros se preocupen de sacar sus kernels parcheados y listo, porque está claro que no hay nadie que use kernels propios que no provengan de una distribución... ¿verdad?
Y bueno, ¿me estás diciendo que las distribuciones iban a coger el 2.4.23-preX y aplicar parches a sus kernels teniendo en cuenta que el parche de 3 líneas no ha sido anunciado como lo que debería ser? ¿Se sabían o no las posibles consecuencias? Si es que sí, un 0 a Tosatti como el que ya se llevó con el ptrace().
Una cosa es que los hackers del kernel no trabajen ni tengan la obligación de hacerlo para los sysadmins ni para nadie, y otra es que tengan las pelotas tan cuadradas de dejar las cosas así durante tanto tiempo. Eso no es serio. "The Linux-way to do things". Cada vez lo entiendo mejor.
Los bugs de seguridad del 2.6 están ahi por que no son criticos. Ya han sido portados al 2.6, simplemente estan esperando para entrar.
Ah, claro, no son críticos. Si me das una shell en tu flamante 2.6 te muestro lo poco críticos que son. ¿O no consideramos los exploits locales como algo crítico?
Y están esperando por entrar... sí, bueno, eso es lo que precisamente hace unas horas hemos podido leer, pero hasta ayer no se sabía mucho del tema, solamente que "alguien" iba a andar con "algo" para ver si todo se arreglaba antes del 2.6.0.
1 El señor tossati no quiere meter libata porque es inteligente, y sabe que 1) libata tiene muy pocos meses desde que salio 2) probablemente ha leido los "asuntillos" sobre corrupciones de fichero con libata en la lista. ¿Quieres soporte de SATA 100% estable para linux? Pues bien, NO LO HAY.
Ya, entiendo, libata no está maduro (por si no lo has leído, estuvo pensando en aceptarlo, pero se retractó).
Entonces supongo que el código de ACPI sí estaba maduro cuando se metió en el kernel, por poner un ejemplo, ¿no? En cuanto a que no hay soporte 100% estable de SATA... Lo que YO he estado probando en MIS kernels, desde *agosto* es bastante más estable que cientos de otras cosas que pueblan el kernel. Eso sí, está claro, eso no significa un 100% de estabilidad ni que otros no vayan a tener problemas... ¿pero quién puede garantizar eso?
2: Tossati no fue quien metio JFS en el 2.4, fue Linus Torvalds.
Error mío. Mi punto era que si JFS se metió entonces, ¿por qué no XFS ahora? ¿¿¿Por qué Tosatti nos manda al 2.6 hablando de _estabilidad_???
Yo solamente veo contradicciones...
Las razones que da ahora son bastante comprensibles: el parche de XFS toca código de *otros* sistemas de ficheros, y el que durante mucho tiempo nadie haya tenido problemas no significa que no los vaya haber (para empezar, la mayoria de la gente solamente usa un sistema de ficheros, asi que a ver cuanta gente ha probado el efecto de los parches de XFS en otros sistemas de archivos).
¿Mande? ¿Que toca código de qué? ¿De cuál de ellos, ext3, reiserfs, jfs,...? Yo creía que era algo intrusivo (concretamente con VFS) pero no que tocara _código específico_ de otro FS. Si fuera así (que va a ser que no, aparte de ser algo completamente ilógico) sería más comprensible.
Ya bueno, y es algo intrusivo, y resulta que tampoco puede entrar porque lleva "pocos meses", ¿no? Lleva un montón de tiempo en entornos de producción, y sí, se ha probado con todo tipo de configuraciones, y no ha dado precisamente más problemas que ext3 durante este tiempo, por poner un ejemplo (si buscas bien
Re:El problema no es de Debian
(Puntos:2)( Última bitácora: Domingo, 08 Agosto de 2004, 01:14h )
XFS usa el mismo codigo base en IRIX y LiNUX. Y en vez de limpiar y adecuar IRIX, quieren meter la mierda en LiNUX.
tema 1000 veces discutido.
Si la gente se dedicase a hablar menos y leer/trabajar mas, no dirian tantas chorradas.
Re:El problema no es de Debian
(Puntos:0)Claro. Y si fuera por el kernel oficial nos quedábamos en pelotas. Es decir, estabilidad y versiones menores sí, cambios de VMs también, pero eso no se lleva para bugfixes que tapan agujeros de seguridad del tamaño de un campo de fútbol.
Pudiendo sacar a la luz una release que corrija un agujero como ese, noooo, "a nosotros eso nos da igual" se deben decir, que las distros se preocupen de sacar sus kernels parcheados y listo, porque está claro que no hay nadie que use kernels propios que no provengan de una distribución... ¿verdad?
Y bueno, ¿me estás diciendo que las distribuciones iban a coger el 2.4.23-preX y aplicar parches a sus kernels teniendo en cuenta que el parche de 3 líneas no ha sido anunciado como lo que debería ser? ¿Se sabían o no las posibles consecuencias? Si es que sí, un 0 a Tosatti como el que ya se llevó con el ptrace().
Una cosa es que los hackers del kernel no trabajen ni tengan la obligación de hacerlo para los sysadmins ni para nadie, y otra es que tengan las pelotas tan cuadradas de dejar las cosas así durante tanto tiempo. Eso no es serio. "The Linux-way to do things". Cada vez lo entiendo mejor.
Los bugs de seguridad del 2.6 están ahi por que no son criticos. Ya han sido portados al 2.6, simplemente estan esperando para entrar.
Ah, claro, no son críticos. Si me das una shell en tu flamante 2.6 te muestro lo poco críticos que son. ¿O no consideramos los exploits locales como algo crítico?
Y están esperando por entrar... sí, bueno, eso es lo que precisamente hace unas horas hemos podido leer, pero hasta ayer no se sabía mucho del tema, solamente que "alguien" iba a andar con "algo" para ver si todo se arreglaba antes del 2.6.0.
1 El señor tossati no quiere meter libata porque es inteligente, y sabe que 1) libata tiene muy pocos meses desde que salio 2) probablemente ha leido los "asuntillos" sobre corrupciones de fichero con libata en la lista. ¿Quieres soporte de SATA 100% estable para linux? Pues bien, NO LO HAY.
Ya, entiendo, libata no está maduro (por si no lo has leído, estuvo pensando en aceptarlo, pero se retractó).
Entonces supongo que el código de ACPI sí estaba maduro cuando se metió en el kernel, por poner un ejemplo, ¿no? En cuanto a que no hay soporte 100% estable de SATA... Lo que YO he estado probando en MIS kernels, desde *agosto* es bastante más estable que cientos de otras cosas que pueblan el kernel. Eso sí, está claro, eso no significa un 100% de estabilidad ni que otros no vayan a tener problemas... ¿pero quién puede garantizar eso?
2: Tossati no fue quien metio JFS en el 2.4, fue Linus Torvalds.
Error mío. Mi punto era que si JFS se metió entonces, ¿por qué no XFS ahora? ¿¿¿Por qué Tosatti nos manda al 2.6 hablando de _estabilidad_???
Yo solamente veo contradicciones...
Las razones que da ahora son bastante comprensibles: el parche de XFS toca código de *otros* sistemas de ficheros, y el que durante mucho tiempo nadie haya tenido problemas no significa que no los vaya haber (para empezar, la mayoria de la gente solamente usa un sistema de ficheros, asi que a ver cuanta gente ha probado el efecto de los parches de XFS en otros sistemas de archivos).
¿Mande? ¿Que toca código de qué? ¿De cuál de ellos, ext3, reiserfs, jfs,
Ya bueno, y es algo intrusivo, y resulta que tampoco puede entrar porque lleva "pocos meses", ¿no? Lleva un montón de tiempo en entornos de producción, y sí, se ha probado con todo tipo de configuraciones, y no ha dado precisamente más problemas que ext3 durante este tiempo, por poner un ejemplo (si buscas bien