| damage | quien ayudara con la traduccion? |
|---|---|
| damage | <riel> ok, me gustaria darles la bienvenida al cierre de sesion de |
| este año en la conferencia de Umeet | |
| damage | este año haremos una sesion de preguntas y respuestas al |
| kernel, parecio ser muy popular la ultima ves que hicimos | |
| damage | una |
| damage | primero quiziera agradecerles a estas personas: |
| damage | a los orgnizadores de umeet, quienes han estado trabajando |
| duro durante estas 2 semanas de la conferencia | |
| damage | a los traductores, quienes han traducido la mayoria de las |
| charlas en #redes | |
| damage | y hoy, posupuesto, a los miembros del panel |
| _libra_ | Hola, voy a empezar la sesion que cierra el ciclo de |
| conferencias umeet de este año | |
| damage | me gustaria introducirlos en orden alfabetico |
| _libra_ | illiam Lee Irwin -hacker de gestion de memoria y escalabilidad |
| _libra_ | Y yo mismo, pero principalmente hoy esty moderando la |
| conferencia | |
| _libra_ | si tienes preguntas puedes realizarlas en #qc |
| _libra_ | asi, los hackers del kernel cortaran y pegaran tus preguntas |
| aqui y las respondera | |
| damage | -- |
| damage | Dave Jones - mantenedor de kernel de Fedore, x86 bajo nivel y |
| device driver hacer | |
| damage | Greg KH - device driver and hacker de modelador de dispositivos |
| damage | Marcelo Tosatti - hacker mantenedor de 2.4 |
| damage | Matthew Wilcox - desarrollador de HPPA Linux, Desarrollador de |
| debian y muchas cosas mas ;) | |
| damage | William Lee Irwin - manejador de memoria y scalabillity hacker |
| damage | y yo, pero solo moderare la charla hoy |
| damage | si tienen alguna pregunta, porfavor haganla en #qc, los kernel |
| hackers copiaran/pegaran su pregunta aqui y la | |
| damage | responderan |
| _libra_ | davej En verdad no tengo suficiente conocimientos sobre |
| selinux como para darte una respuesta, lo siento | |
| _libra_ | <riel> ok, alguna otra pregunta |
| _libra_ | ? |
| _libra_ | <rene> gregkh: cual es tu opinion acerca del actual estado del |
| modelo de dispositivos? hacia donde te gustaria que se dirigiera? | |
| _libra_ | ele stado actual es bastante bueno. Es estable y funciona para |
| casi todos | |
| _libra_ | como he dicho, hay algunas cosas en las que aun tenemos que |
| trabajar | |
| _libra_ | bloqueo- el bloqueo interno del modelo del dispositivo y sysfs |
| necesita ser remodelado para que nos permita hacer cosas mas avanzadas. Estare | |
| con esto el mes viniente | |
| _libra_ | soporte de clases- Necesitamos dar soporte a hijas de las |
| clases de dispositivos para que podamos mover /sys/block a /sys/class/ | |
| damage | - manual bind/ o unbind de dispositivos. nescestamos echar una |
| mirada a los cambios finalizados, entonces podemos | |
| > ohhhhh que faena | |
| EOF from client) | |
| -> *one2* op #redes damage | |
| _libra_ | -hacer las cosas mas simples, En algunas partes aun es |
| demasiado dificil usar el modelo de drivers. Necesitamos mas cosas como el | |
| interfaz class_simple | |
| _libra_ | -y acabando, mejorar la documentacion. Pero LDD3 ayudara a |
| solucionar esto | |
| _libra_ | <mcr> He estado usando User-Mode-Linux para testeo de los |
| nightly builds del codigo de KLIPS IPsec. Esto ha sido bastante eficiente. Me | |
| gustari ver mas de estos testeos regresivos de nightly builds en UML sobre | |
| drivers no-hardware. Quiza los que entiendan de ensamblador podrian decirnos | |
| que estan usando para testear mas extensivamente con UML | |
| _libra_ | Intentare dar una respuesta corta a mis pregutnas ;) |
| damage | actualmente estoy planeando usar la visualizacion de Xen para |
| probar y he usado el | |
| damage | Mode Linux para debugiar el codigo del kernel, como sea, uml se |
| comporta diferentemente | |
| damage | del nucleo verdadero en algunos aspectos y depende del nucleo |
| para realizar su comportamiento | |
| damage | se que *people cluster* y algunos desarrolladores de red estan |
| usando UML para probar | |
| _libra_ | <EricB> Parece que la mayoria de los venddedores ahora venden |
| sus propios kernels. Es esto un problema o estan haciendo bien los vendedores | |
| enviando parches para su inclusion en linux? | |
| _libra_ | Los vendedores historicamente han vendido sus propios kernels |
| _libra_ | y solian tener muchas mas divergencias con el kernel que las |
| que tienen actualmente | |
| _libra_ | Los vendedores de distribuciones estan mandando parches mejor |
| que nunca antes. | |
| _libra_ | En particular, Los vendedores de hardware estan cogiendo el |
| mensaje de que necesitan mandar el codigo de sus API's en vez de programar las | |
| extensiones para las distribuciones antes. | |
| reset by peer) | |
| > algun voluntario más puede traducir ? | |
| Max | :/ |
| Max | si supiera :/ |
| > riel> como uno de la gente de la distribución, tengo otra cosa a | |
| agregar a esto;), dos cosas, realmente | |
| > 1) las distribuciones de Linux tienen un equipo del QA quizá de | |
| algunos docena personas, mientras que el núcleo por aguas arriba tiene millón | |
| de usuarios - así que cualquier cambio que una distribución haga es menos bien | |
| probado que el núcleo por aguas arriba, y un riesgo | |
| _libra_ | Actualmente estoy planeando usar la visualizacion de Xen para |
| testeo | |
| > 2) es muchos de trabajo virar remiendos hacia el lado de babor a | |
| partir de una versión del núcleo al siguiente, así que para las distribuciones | |
| de Linux ahorra realmente el trabajo si sus cambios se envían al núcleo por | |
| aguas arriba primero | |
| > davej > de una perspectiva del fedora, estamos teniendo como objetivo | |
| realmente enviando menos remiendos con cada lanzamiento, y consiguiendo más | |
| cercano a esa meta cada vez. | |
| > davej > FC3 eran alrededor 40-50 remiendos lejos del mainline en la | |
| época del lanzamiento, y muchos de ésos eran cosas de la fijación de los | |
| backports del poste 2,6,9 varias. | |
| > davej > después del lanzamiento de FC3, las actualizaciones | |
| subsecuentes ha aumentado la cuenta del remiendo algo, pero otra vez, la | |
| mayoría de ésos son arreglos del poste 2,6,9 tomados de contra la corriente. | |
| > davej > los únicos pedacitos que no son, empujados contra la corriente | |
| de modo que cuando el núcleo basado 2,6,10 del fedora es rebasado, consigamos | |
| tomar esos arreglos para libre. | |
| > gregkh > y, como uno de los sostenes del núcleo de Gentoo, nuestro | |
| árbol del núcleo tiene solamente 5 remiendos que no estén por aguas arriba ya. | |
| > davej> impresionante 8) | |
| _libra_ | y etos seran aceptados dentro de poco |
| _libra_ | <damjan> gregkh: mientras que en el modelo de dispositivos, en |
| cuanto a la gestion de energia esta correcto, la implementacion de los drivers | |
| es pobre o necesita que se trabaje mas en ella? | |
| _libra_ | aun se esta trabajando duramente en la gestion de energia y en |
| su diseño. Si te interesa unete a la lista de linux-pm | |
| _libra_ | lista que esta hospedada por osdl |
| > riel > < trulux > riel ¿cuál es la opinión de los hackers del núcleo | |
| en puestas en práctica de NX y realces de la protección de la memoria: | |
| ¿Protector de Exec, PaX.... etc? | |
| _libra_ | <trulu> riel, Cual es la opnion de los haclers del kernel en |
| cuanto a a la implementacion y las mejoras en el manejo de memoria de NX: Exec | |
| Shield, PaX... | |
| _libra_ | <riel> ok, tengo una opnion-no-estandar sorbe esta pregunta :) |
| _libra_ | Se que PaX protege contra algunas cosas contra las cuales no |
| protege Exec-Shield | |
| _libra_ | de todas formas, creo que los administradores de sistemas |
| preocupados (aca paranoicos) no son los principales objetivos de estos parches | |
| _libra_ | el objetivo principal es proteger a los sistemas que no tienen |
| las actualizaciones de seguridad inmediatamente | |
| _libra_ | por eso pienso que la mejor de las dos soluciones es aquella |
| que se pueda aplicar sin destrozar ingun programa | |
| _libra_ | asi, los administradores de sistemas no tendran que desactivar |
| ningun sistema de seguridad | |
| _libra_ | Fedora tambien tiene soporte para execshield y me alegra saber |
| que otras distribuciones (debian y gentoo) estan endureciendose | |
| > gregkh > < roel > con el nuevo modelo del desarrollo, teniendo un | |
| menos núcleo de los estable-en-todo-tiempos, no dependeremos aún más de | |
| núcleos remendados de la distribución? | |
| > gregkh > roel: usted dependió siempre de una "distribución remendada" | |
| si usted deseó un árbol estable del núcleo. | |
| > gregkh > ahora apenas tenemos finalmente reconocido lo que hemos | |
| estado haciendo por años. | |
| > gregkh > ese tenemos un ciclo de desarrollo relativamente activo del | |
| núcleo, y si usted desea un núcleo probado y apoyado, utilizamos un distro. | |
| > el gregkh > si usted desea la ayuda y los bugfixes más últimos del | |
| hardware, utiliza un distro ese mainline de las pistas rápidamente, (como | |
| like Fedora, Debian and Gentoo.) | |
| _libra_ | si quieres "estable y que no cambie en 5 años" mejor usa una |
| distribución empresarial como RHEL o SLES | |
| _libra_ | ahí tienes la opcion |
| _libra_ | <willy> Solo tengo una distribucion con el kernel parcheado en |
| una de mis maquina | |
| _libra_ | todas las demas (incluida la de mi mujer) corren en kernels |
| que he compilado yo mismo | |
| _libra_ | Son suficientemente estables, su portatil corre un 2.6.5 y ha |
| estado conectado durante 135 dias | |
| _libra_ | <trulu> riel, también, los portes jails de FreeBSD van a ser |
| integrados en el kernel? | |
| _libra_ | <riel>ok, esta pregunta tiene varias respuestas ;) |
| _libra_ | primero, Linux _ya: tieneun parche disponible similar a BSD |
| jail, se llama vserver | |
| _libra_ | y la gente lo usa de la misma forma |
| _libra_ | selinux puede ser usado para restringir lo que los programas |
| pueden hacer, aunque requiere mas cuidado con las herramientas adecuadas | |
| _libra_ | Creo que la configuracion de selinux deberia ser manejable, |
| por supuesto, en ambos casos tu sistema es vulnerable a exploits del kernel | |
| _libra_ | esto nos lleva a la tercera respuesta de tu pregunta: |
| virtualizacion | |
| _libra_ | si corres servicios inseguros en su propia maquina virtual, |
| con su propio kernel, incluso un exploit de kernel local dejaria el resto de | |
| tu máquina intacta(corriendo otras maquinas virtuales) | |
| > willy > < weasel > no una pregunta muy técnica, pero uno con respecto | |
| a la política del lanzamiento. Toma actualmente a menudo muchas semanas hasta | |
| que los problemas sabidos de la seguridad consiguen fijados no solamente en | |
| BK, pero en un lanzamiento. ¿Usted atento hace uso los lanzamientos de | |
| x.y.z.N que fijan tales insectos críticos rápidamente en el futuro, o por lo | |
| menos hizo remiendos sabidos más extensamente? | |
| > willy > convengo con weasel que no hacemos un trabajo muy bueno de la | |
| fijación/de anunciar arreglos de bits de la seguridad. No he oído la mención | |
| de Linus o de Andrew un deseo de hacer lanzamientos de punto de la seguridad; | |
| Sospecho que no están interesados en él ellos mismos y si se asume que si hay | |
| suficiente interés, alguien paso adelante de la voluntad para tomar el cuidado | |
| de él. | |
| > riel > las distribuciones están tomando el cuidado de él;) | |
| > willy > bien, las distribuciones están tomando el cuidado de él para | |
| sus propios núcleos, pero el it'd sea agradable si alguien intensificado para | |
| manejar los remiendos de la seguridad para los núcleos de kernel.org. | |
| > davej > willy: qué Alan ha estado haciendo a un cierto grado en el | |
| suyo - los núcleos de la CA. Pero convengo, un subrelease verdadero del 1 | |
| sería mejor | |
| damage | <riel> ahora una buena pregunta, y no tengo una buena |
| respuesta.. | |
| damage | <riel> <ducky> que piensas respecto a que las barreras mas |
| fuertes de las empresas estan migrando sus | |
| damage | servidores a 2.6 |
| damage | <davej> no hay 2.7 para el backport fresco de la empresa todavia |
| damage | <gregkh> y gente que no espera por las cosas que esten rotas |
| damage | <riel> yo creo que una de las razones es que 2.6 no ha sido |
| probado bien en ambientes de produccion. | |
| damage | hay pocas personas en la lista de correo del linx-kernel que |
| corren una base de datos en 16 CPU System | |
| damage | con 54GB de memoria - entonces quien sabe si trabajan bien? |
| damage | <willy> posiblemente ellos estan usando dispositivos realmente |
| viejos que no trabajan aun en 2.6 | |
| damage | <EricB> habra algun esfuerzo para dividir el codigo por |
| arquitectura?, la mayoria de las personas nescesitan | |
| damage | uno o dos |
| damage | <willyZ> no, no hemos ajustado el / del codigo fuente, cuando |
| podria ser facil para las personas que bajan el | |
| damage | tarball del kernel, seria mas carga para los mirrors y en los |
| desarrolladores. los archivos .diff no son grandes, | |
| damage | solo nescesitas bajar una copia del tarball |
| damage | <marcelo> <ducky> cual es tu experiencia como un mantenedor del |
| kernel 2.4? | |
| damage | he leido mucho estos años, acerca de la relacion con otros |
| desarrolladores/miembros de la comunidad y tambien | |
| damage | acerca de importantes cosas tecnicas. y he interactuado con un |
| largo numero de desarrolladores. | |
| damage | mantener el estable del linux kernel es una gran |
| responsabilidad, y es un gran comite. ha ocupado la mayoria de mi tiempo | |
| damage | durante estos años, no es una tarea facil - uno se siente |
| responsable de todos los bugs que aparecen, y que | |
| damage | pueden ser tiempos muy frustrantes. mi tiempo por mi tiempo |
| damage | pero a las finalez ha sido maravilloso como experiencia |
| personal, y he leido mucho para seguir haciendolo | |
| damage | <willy> mcr solicito otra opinion aparte de riel sobre UML, la |
| mayoria de mis cambios al kernel son hardware, | |
| damage | por eso boteando UML ayudaria porla prueba de todos mis |
| cambios, por personas que les gusta el desarrollo en redes | |
| damage | y quizas VM hackers, UML es genial, pero cuadno tu nescesitas |
| alteras driver de dispocitivos o PCI bus walking code, | |
| damage | no es muy bueno, tambien, un monton de tiempo he trabajado en |
| cosas como es ia64-specific, y no creo que haya | |
| damage | UML para ia64 todabia. |
| damage | <gregkh> <mb_> que hay de BKL, podemos esperar a que algun dia |
| desaparesera? trabajan en el? | |
| damage | <gregkh> hay un trabajo pequeño en bkl tratando de librar los |
| ictl calls, pero | |
| damage | el mayor trabajo de "get rid of the bkl" esta terminado, los |
| desarrolladores que trabjaron en el estan | |
| damage | haciendo otras cosas ahora, y menos de eso hay muchos |
| beneficios para borrar sus restos del kernel, pienso que | |
| damage | nunca se podra ir completamente |
| damage | <willy> hay muchas partes del kernel que usan BKL, pero la |
| mayoria de ellos infrecuentemente llamadas paths, | |
| damage | contenido en el BKL es muy poco en estos dias, hay mucho mas |
| interes en problemas de atake en terminos de | |
| damage | scala |
| damage | <riel> <warren> Q: aun estamos plagados de los problemas de |
| valanceo de VM? nunca terminaran? | |
| damage | <riel> el VM es el gran problema que nadie ha podido hacer |
| hacer, entonces no es posible crear un test set que | |
| damage | se asegure que eso es una buena cosa |
| damage | <riel> por esa rason, yo sospecho que que tendremos problemas |
| de balanceo de VM por mucho mas | |
| _libra_ | tambien, la VM tiene tendencia a romperse cuando la optimizas |
| demasiado, asique si la optimizas para unas pruebas, seguramente haras que | |
| decaiga el rendimiento | |
| _libra_ | este es un problema fundamental, porque la VM tiene que |
| cambiar _algo_ cuando tiene poca memoria | |
| _libra_ | y siempre hay un programa que usará esta memoria en el futuro |
| _libra_ | la tarea de la VM es cambiar la pagina que hace pero la VM lo |
| menos posible | |
| _libra_ | <rene> a proposito del topic. donde _esta_ el espacio de |
| usuario del inicio? | |
| _libra_ | <gregkh> el codigo del "espacio de usuario del inicio" ya esta |
| en el kernel 2.6 de hoy | |
| _libra_ | mira en el codigo de initramfs, hay documentacion sobre como |
| usarlo en la carpeta Documentation. La gente todavia esta trabajando en | |
| embeber el codigo de klibc en el arbol del kernel | |
| _libra_ | cuando esto este hecho, podremos empezar a colocar piezas de |
| la logica del proceso de arranque del kernel duera del espacio del kernel y en | |
| el espacio del usuario, aun manteniendolo como parte del desarrollo del kernel | |
| _libra_ | para mas info sobre esto, mira los archivos de la lista de |
| klibc | |
| _libra_ | <tklauser> Como testean su codigo los desarrolladores de |
| drivers y hackers del kernel? No es dificil corregir el codigo a tan bajo | |
| nivel? | |
| > willy > pienso la gente cree que hay una cierta clase de mistica para | |
| hacer el kernel. No hay tal, realmente. Es justo que cuando usted escribe mal | |
| código, se estrella la máquina entera, no apenas el programa que usted | |
| escribía. Probamos tan nuestro código en mucho la | |
| > misma manera que lo hacen otros hackers. Cada uno diferente; Tiendo | |
| para escribir código, lo compilo, el arreglo compilo problemas, lo pateo | |
| (generalmente en una diversa máquina; -), fije los problemas del | |
| > cargador, tensiónelos, fije esos problemas. Una vez que no pueda | |
| romperlo más, lo envío hacia fuera para que la gente intente romperlo. Ella | |
| generalmente... | |
| > riel > < krocz >: riel, ¿ cómo debería funcionar grsecurity con | |
| xen?. | |
| > Bien, cada huésped de Xen funciona su propio núcleo así que debe ser | |
| relativamente fácil funcionar grsecurity en tal núcleo las únicas piezas que | |
| pueden necesitar virar hacia el lado de babor son el específico de la | |
| arquitectura unos, pero ésos deben ser pocos | |
| _libra_ | <damjan> Cual es la sensacion general entre los hackers del |
| kernel sobre el sistema de archivos del espacio del usuario(como FUSE), | |
| cobrara importancia en el futuro? tambien, que hay de los espacios de nombre | |
| VFS por-usuario( o por-proceso), Tambien, que hay de la superposicion delos | |
| mounts? | |
| _libra_ | Los chicos de FUSE estan bastante interesados en que se |
| incluya su codigo | |
| _libra_ | Linus encontro algunos problemas en el, pero creo que ya los |
| han corregido | |
| #redes | |
| _libra_ | Si persisten, continuan corrigiendo errores y no son muy |
| irritantes, el code se integrará pronto | |
| _libra_ | los espacios de nombre VFS por-proceso ya estan implementados. |
| Creo que la superposicion de mounts puede suerarse más facilmente escribiendo | |
| un nuevo sistema de ficheros(creo que es asi como lo hace BSD). Asique es | |
| bastante facil, escribe un nuevo sistema de archivos! | |
| > riel > < krocz >: riel, ¿ qué partes del núcleo del linux hacen el | |
| remiendo de Xen?. Xen es una nueva pseudo-arquitectura, como el modo Linux | |
| así que él del usuario remienda arch/xen/y agrega algunos drivers de | |
| dispositivo virtuales específicos de Xen que reutiliza partes grandes de | |
| arch/i386/para evitar la duplicación del código y los toca un poco de código a | |
| otra parte | |
| damage | <riel> <warren> Q: en el topic de los sistemas de ficheros, que |
| se tomara para abilitar mount --bind -o para | |
| damage | tener un sistema de ficheros solo-leida en ese lugar, |
| leer-escribir en otro simultaneamente? existen parches | |
| damage | (de autores de vserver) den 2.6 que fueron lanzados hace pocos |
| meses atras. ningun trabajo en esta direccion? | |
| damage | <riel> No estoy enterado de trabajo adicional aquí, aunque la |
| gente del vserver puede todavía trabajar en él. | |
| damage | <willy> <damjan> yo tambien tengo una pregunta acerca de |
| improvisar *robustness en el kernel, | |
| damage | ¿si usted consiguió los procesos stucked en alguna parte en el |
| núcleo (que espera en el NFS, CIFS o el mal CD) | |
| damage | la única cosa que usted puede hacer es un recomenzar... puede |
| algo ser hecho sobre él? | |
| damage | actualmente, Linus fijó un contorno de una manera de dirigir |
| esto hace algunos años. | |
| damage | http://seclists.org/lists/linux-kernel/2002/Aug/0467.html |
| damage | nadie a implementado todabia, tu puedes ser uno de esos |
| damage | <riel> ok, parece que estamos listos en preguntas (y fuera de |
| tiempo) ahora, gracias a todos por asistir a este | |
| damage | año de conferencias en umeet, le pasare el microfono virtual a |
| MJesus, quien cordina umeet | |
| damage | <willy> queria agradecer a Rik por su esfuerzo en herding cats |
| (aka organzando el kernel hackers) | |
| damage | <riel> queria agradecer a todos los presentados, panel de |
| miembros, organizador de conferencias, traductores... | |
| damage | y porsupuesto a la audiencia |
| krocz | EXCELENTE!!! |
| krocz | gracias damage _libra_ y MJesus |
| krocz | CLAP CLAP CLAP CLAP CLAP CLAP |
| krocz | CLAP CLAP CLAP CLAP CLAP CLAP |
| krocz | CLAP CLAP CLAP CLAP CLAP CLAP |
| krocz | CLAP CLAP CLAP CLAP CLAP CLAP |
| #redes | |
The Organizing Comittee
