Tráfico del Núcleo #101 For 8 Jan 2001

Lo siento, no hay nada en este ejemplar acerca de la presentación de 2.4; de hecho, este número de TN cubre el corazón de la temporada de fiestas Cristianas, así que no hay tanta discusión en la lista como es habitual. Sintoniza la próxima semana para discusiones acerca de las nuevas series estables.

There were 230 different contributors. 105 posted more than once. 0 posted last week too.

Robert B. Easter preguntó cuáles eran las versiones de compilador recomendadas para las series 2.2.18 y 2.4-test. Para 2.2.18, Barry K. Nathan recomendó "gcc 2.7.2.3 es más seguro, pero egcs 1.1.2 debe ser seguro aún para cosas de misión crítica. gcc 2.95.2 parece funcionar para mucha gente, pero no es necesariamente segura." Para 2.4 recomendó, "egcs 1.1.2 es la opción segura, pero gcc 2.95.2 parece funcionar. gcc 2.7.2.3 compila con errores 2.4 más seguido que sin ellos, así 2.4 tiene una revisión de preprocesador que detiene cualquier intento de compilarlo con 2.7.2.3." Agregó que el fichero Documentation/Changes podría resolver la pregunta del compilador para cada versión liberada en particular. En otro lado, Linus Torvalds dijo en cierto punto:

Noten que a pesar de mis comentarios públicos acerca de ser una mala idea distribuir compiladores extemadamente sin probar en una versión liberada mayor, actualmente pienso que sería maravilloso tener gente que esté lista para enfrentar las consecuencias que pruebe el nuevo 2.96.

No ha sido tan ampliamente probado, pero si sabes un poco acerca de lo que estás haciendo (o quieres aprender), gcc-2.96 potencialmente _crea_ mejor código, y si nadie está dispuesto a probarlo, cualquier bug potencial (sea en las fuentes del núcleo y activado por un compilador más listo, o en el compilador mismo) no se encontrarán.

Así que por favor inténtenlo, pero por favor mencionen el hecho si terminan teniendo que reportar un bug (no hará que su reporte de bug sea ignorado, no se preocupen siquiera por algo así. Pero sería bueno tener un compilador más viejo a la mano para correlacionar el bug con el compilador para asegurar).

De hecho, amaría escuchar acerca de experiencias aún con las muestras CVS. Sólo no me gusta verlas aparecer en distribuciones ;)

En respuesta, Matthew Vanecek reportó que las últimas actualizaciones de gcc 2.96 de Red Hat han estado funcionando bien para sus compilaciones del núcleo.

En otro lado, Alan Cox también listó los compiladores recomendados por Robert, agregando, "El 2.96 de Red Hat parece generar núcleos válidos, pero no esperen comprensión si reportan un bug en uno construído de esa forma." Y Linus continuó, en respuesta:

Ahora, ahora, amaría ver reportes del nuevo compilador actualizado expecialmente. Actualmente no he visto un solo reporte de problemas con el núcleo aún con el 2.96 antiguo, es sólo que he visto muchos problemas en el espacio de usuario que vacilaría usarlo para el núcleo.

A pesar de mi disgusto de distribuir compiladores muestra, sería _mucho_ mejor ver a Red Hat desechando su cosa "kgcc", para hacer que la gente necesite probar con el nuevo compilador.

Sólo quiero que la gente mencione el hecho, así yo puedo correlacionar cualquier reporte de bug con una versión del compilador. Sólo por si acaso. Puede ser importante (y no solo por bugs del compilador, pero debido a bugs reales del núcloe que tan sólo has estado ocultos por pura suerte con otros compiladores). Y ayuda MUCHO si tienen otro compilador disponible para comparar.

Mike A. Harris dió un vínculo al la Página del Proyecto del Linux de NSA con Seguridad Mejorada y preguntó si alguien la había visto. Alex Buell recomendó paranoia, diciendo que sería prudente buscar puertas traseras antes de incluir cualquier código de NSA. Pero en otro lado, Casey Schaufler dijo, "Las personas buscando por puertas traseras, trucos, engaños, trampas, o hielo van a estar decepcionadas. Es tan sólo código como el que cualquier otro produce. Mucho del trabajo fue hecho por empleados de la NSA. Ellos deben ser aplaudidos por el esfuerzo que pusieron sólo para ser permitido hacer esto disponible."

Sandy Harris replicó, "Estas gentes son buenas en lo que hacen y el código es GPL. Vale la pena comenzar a considerar si este código, o código de alguno de los otros proyectos de mejora de seguridad, deben ser incluídos en el núcleo estándar para 2.6 o 3.0" Alan Cox replicó, "Pienso que es un buen punto. Esto es actualmente un buen testimonio para el software libre que finalmente obtuvo que la NSA contribuyera código en una forma que todos se benefician y que puede ayudar a cortar crímenes computacionales más allá del gobierno. (y que por supuesto actualmente es parte del trabajo verdadero de NSA)" Y James Lewis Nance acreditó, "Con frecuencia me pregunto cuánta gente sabe que un gran montón del código de red de Linux tiene Copyright de la NSA. Estoy siempre esperando escuchar a alguien salir con una teoría de conspiración acerca de eso en slashdot, pero nunca he escuchado a nadie mencionarlo."

En otro lado, Alan remarcó, "Estoy seguro que todo tipo de gente estará encontrando bugs en él porque están buscando por puertas secretas de NSA así que por qué desanimarlos 8)." Michael H. Warfield replicó, "Ahora que es un buen maldito punto real que no había pensado. Con todos tan paranoicos acerca de qué puertas traseras habrán dejado puestas (como si fueran tan locos de introducirlas y sacarlas a plena vista de todos) que el código debe terminar obteniendo una revisión realmente buena también. :-) Que trato. :-)"

Me pregunto cómo se compara su aproximación a las cosas de RSBAC, creo. El RSBAC (por Amon Ott) tiene toda la infraestructura disponible para tener control de acceso basado en políticas; cada vez que una decisión de acceso tiene que ser tomada, una llamada a través de alguna interfaz es hecha a un módulo, el cual toma la decisión ... Justo como PAM en espacio de usuario. http://www.rsbac.org/

Pienso que es una buena aproximación y pienso, que ha ido mucho más allá que las cosas de NSA. Preferiría tener RSBAC integrado en 2.5.

El Linux con Seguridad Mejorada tiene una arquitectura bien definida (llamada Flast) para controles de acceso obligatorios flexibles que han sido validados experimentalmente a través de varios sistemas prototipo (DTMach, DTOS y Flask). La arquitectura provee una separación limpia entre política y aplicación, interfaces de decisión de políticas bien definidas, flexibilidad en el etiquetado y decisiones de acceso, soporte para cambios de política, y controles de grano fino sobre las abstracciones del núcleo. Se han realizado estudios detallados de la capacidad de la arquitectura para soportar una amplia variedad de políticas de seguridad y están disponibles en las páginas web de DTOS y Flask accesibles a través de la página de Background (http://www.nsa.gov/selinux/background.html). Un documento publicado acerca de la arquitectura Flask también está disponible en la página de Background. La arquitectura y su implementación en Linux está descrita en detalle en la documentación (http://www.nsa.gov/selinux/docs.html).

RSBAC parece tener metas similares al Linux con Seguridad Mejorada. Como el Linux con Seguridad Mejorada, separa política de aplicación y da soporte a una variedad de políticas de seguridad. RSBAC usa una arquitectura diferente (el Marco de Trabajo Generalizado para Control de Acceso o GFAC [por sus siglas en inglés]) que el Linux con Seguridad Mejorada, aunque el documento de Flas anota que en el más alto nivel de abstracción, la la arquitectura Flask es consistente con el GFAC. De cualquier forma, el GFAC no parece manejar en su totalidad el asunto de cambio de políticas y revocación, como se discute en el documento de Flask. RSBAC también difieren en la especificación de sus interfaces de políticas y sus controles, pero una evaluación cuidadosa de la significancia de estas diferencias no se ha realizado.

algunos chips de BIOS para PC están viniendo con una configuración Microsoft por omisión, la cual los hace hostiles a algunas funcionalidades de otros OS. En particular bajo Linux, un Winmodem PCI NO funciona con la configuración de BIOS de Win98, pero lo hizo bien bajo la opción de BIOS "Other OS". Posiblemente, otros dispositivos PCI bajo el SO Linux puedan ser similarmente afectados.

Esto indica una necesidad para software de instalación de Linux que sea equipado con una utilidad que pruebe el BIOS y reporte configuraciones de BIOS "hostiles a Linux". Hoy muchos Novatos están consiguiendo nuevas PCs equipadas con WinModems. Las configuraciones hostilies de BIOS bloquearán su capacidad para estar en línea.

David Riley replicó, "No pienso que esto pueda ser necesariamente clasificado como "hostil a Linux", pero realmente más como "ignorante de Linux". En la mayoría de las configuraciones decentes de BIOS, la opción "Window" en tu configuración se leería como "SO PnP". Los escritores de tu bios tan sólo asumieron que Windows es el único SO que funciona adecuadamente con PNP (debido a que hasta de forma reciente eso no estaba lejos de la verdad). En cualquier caso, usando un núcleo algo nuevo (como 2.4.0-test12, pienso) debe solucionar los problemas manejando adecuadamente las cosas de PnP."

Rik van Riel envió un parche a Jeff Garzik, y Andre Hedrick replicó, "Jeff Garzik, está fuera de línea por las siguientes tres semanas...... Clama que sus muñecas le duelen por el teclado ;-)..." Mike Galbraith replicó:

Y si sus muñecas duelen, él está definitivamente haciendo lo correcto al descansar.

Yo _sé_:

8 meses con un collarín debido a daño cervical en la columna (no jorobarse hacia adelante mientras se lee código cool/listo). 1.5 años de terapia física por ese daño (permanente, _no_ jorobarse hacia adelante mientras se lee código cool/listo). 7 meses de parálisis del brazo izquierdo (no recargarse en el codo sobre superficies duras mientras se lee código cool/listo) 5 meses de parálisis en la parte baja de la pierna izquierda (no cruzar las piernas mientras se recarga en el codo izquierdo mientras...).

El daño nervioso puede ser aliviado un poco con dosis masivas de vitamina B si eres afortunado, pero no se recupera totalmente en mi experiencia. Los huesos no se recuperan.. nunca.

¿Recuerdan las cientos de veces que su mamá les dijo que se sentaran derechos? Estoy seguro que sí ;-)

</melodrama>

Soy una de las gentes que trabaja en la porción de PowerPC del núcleo. He notado desde hace tiempo que lo que está disponible en kernel.org y lo que ha sido trabajado por algunos de nosotros que mantenemos nuestra pequeña porción en el árbol de PowerPC está más y más fuera de sincronía.

Cómo es que llegamos aquí etc etc etc a este estado no es importante. Primero cómo componerlo y como asegurarnos de que no suceda otra vez me concierne.

Actualmente el diff entre test13-preX y el árbol maestro de ppc en fsmlabs.com es de cerca de 450k. ¿Es lo correcto empezar con que ese parche entre en las series test13-preX?

REALMENTE apreciaría si esto puede ser hecho que suceda. Tengo una carga completa de hardware RS/6000 (aka pSeries) que estaría empezando a trabajar una vez que este parche esté dentro. Es de verdad una vergüenza tener que explicar a la gente que kernel.org *DEBE* ser el lugar para obtener un buen núcleo, pero dado que las cosas están fuera de sincronía tener que dirigirlos a otro lado más.

Rik van Riel surigió enviar parches a Linus Torvalds o Alan Cox, pero Tom replicó, "test13-pre5-acXX está al-día con todo lo que es importante de todas forma. Lo que sea que lo logre dentro del árbol de Linus es la parte importante y desconocida."

Frank Davis obtuvo algunas referencias indefinidas en network.o, mientras trataba de compilar 2.4.0test13-pre6; Andrew Morton publicó un parche para componerlo, y Alan Cox explicó, "Mi falta. Envié a Linux unas cuantas cosas demasiadas tratando de tener las cosas de red limpiadas. Algunas cosas se fugaron de las composturas del núcleo de red que no están aún en el árbol de Linus."

Alan Cox anunció 2.4.0test13pre7-ac1 y explicó, "Esto es para ayudar a dar a la gente una idea de qué cosas -ac han sido empujadas a Linus, están aún en necesidad de trabajo, han sido desechadas en la cubeta de malas ideas etc." Tom Rini preguntó si el transporte de PowerPC había sido arrojado a la cubeta, y Alan replicó, "Puede ser que el transporte de ppc sea 2.4.0ac1 y 2.4.2 Linus o algo. No pienso que pueda ser un gran problema. Necesito llegar al tope de 2.2.19pre4 y el resto de la resincronización con Linus y entonces voy a sacar bloques de cosas fuera de -ac y tratar y tener un árbol -ac bien limpio. Si las gentes quieren sincronizar transportes no x86 con eso inicialmente adelante." Tom replicó, "Oh bien. Creo que nuestro problema es que nunca podemos hacer que Linus note los bloques más pequeños y él siempre parece odiar los parches grandes."

RAJESH BALAN preguntó, "¿linux da soporte a Colas de Mensajes Posix? Me estoy refirienndo a richard stevens V2 para IPC.. El libro dijo que incluya <mqueue.h>, el cual no pude encontrar. Estoy usando Linux 2.2." Gabi Davar replicó, "Las Colas de Mensajes POSIX no están aún implementadas en glibc v2.2 (los semáforos POSIX están parcialmente implementados). Una vez que glibc los soporte, puedes probar por su existencia a través de sysctl() y los defines relevantes. Hasta donde yo sé, Linux solamente implementa Colas de Mensajes SysV. Solaris y Tru64 las implementan creo."


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	21 Dec 2000 - 26 Dec 2000	(14 posts)	Versión De Compilador GCC Recomendada
2.	22 Dec 2000 - 26 Dec 2000	(12 posts)	El Linux de NSA Con Seguridad Mejorada
3.	25 Dec 2000 - 26 Dec 2000	(4 posts)	Algunos BIOSes Favoreciendo A Microsoft
4.	28 Dec 2000 - 29 Dec 2000	(3 posts)	Lesiones Por Tensión Repetitiva
5.	29 Dec 2000	(3 posts)	El Árbol De PowerPC Desactualizado
6.	30 Dec 2000	(3 posts)	Algunos Cables Cruzados Con Envío De Parche
7.	30 Dec 2000	(4 posts)	Estado Del Transporte De PowerPC En El Árbol Oficial
8.	30 Dec 2000 - 31 Dec 2000	(2 posts)	Colas De Mensajes POSIX

Tráfico del Núcleo #101 For 8 Jan 2001

By Zack Brown

Translated By: Cristian Othón Martínez Vera