@Arador	la traduccion empieza, los que puedan ayudar a traducir a #ecolog
@Arador	sarnold: me gustaria dar la bienvenida a todos para el evento final de la Umeet de este año
@Arador	y tenemos la suerte de tener aqui a dave jones, robert love, andrew morton, y posibles apariciones de rik van riel, greg kroah-hartman, chris wright, pat mochel, y otros :)
@Arador	preguntas a #qc
@Arador	con esto, vamos a hacer salgunas preguntas genericas:
@Arador	QQque creeis que son las mayores mejoras para los usuarios en el kernel 2.5?
@Arador	*davej espera que rml grite preempt
@Arador	rml jaja
@Arador	rml: no no, es la VM :)
@horacio	1) manejablidad de dispositivos mejorada (cuando lo termine)
@horacio	2) menor latencia cuando haya mucha escritura
@horacio	la manejabilidad de dispositivos es importante para "grandes" usuarios.
@horacio	El tema de la latencia para equipos de escritorio
@horacio	el manejo de dispositivos es importante también para "pequeños usuarios" que quieren saber cual USB es cual.
@Arador	rml: en general mejor acople de VM y gestion de disco
@Arador	gregkh: la manejabilidad es tambien util para los "pequeños usuarios" que quieren decir que unidad usb es cual
@Arador	sarnlod: rml: recuerod leer que uno de los objetivos de marshall kirk mckusick es ver a la gestion de memoria y de disco finalmente "dentro"...que piensas que esto significa para un diseñador de sistemas operativos (en adelante SO?)
@Arador	andre: esa es una pregunta facil y una de las cosas que la mayoria de nosotros olvida atacar: mulix: que cambio creeis que es el mas importante para los desarrolladores "fuera del arbol"?
@Arador	rml: significa que estan enteraamente integrados, y en realidad, son la misma cosas. Todo va a traves de la VM (getion de memoria), asique necesitan estar bien acoplados
@Arador	gregkh: mulix los multiples cambios de api que han cambiado. Hay muchos para los drivers
@Arador	sarnlod: que significa la integracion de la vm y el IO (gestion de disco) significa para aplicaciones como bases de datos?
@Arador	davej: he estado queriando hacer una version de mi documento post-halloween para un punto-de-vista-hacker, pero no he tenido tiempo para hacerlo todavia
@runlevel0	<sarnold> rml: algo que te perdiste al reconectar...
@Arador	davej: Intentare hacer lo basico, postearlo, y dejar que el resto haga lo demas ;)
@runlevel0	<akpm> mi secreto es evitar los drivers
@Arador	akpm: andre: el quitar el cli()/sti() y los cambios de cierres afectan al exterior del kernel un monton
@Arador	imbezol: Seria posible una rapida introduccion de los hablantes...que hacen cada uno de ellos?
@Arador	ah si, introducciones ;)
@Arador	sarnold: andre es el master del IDE
@Arador	sarnold: bacchus es el master de MIPS
@Arador	sarnold: cdub y gregkh hacen LSM, gregkh ademas hace USB
@Arador	sarnold: mochel hace gestion de dispositivos
@Arador	sarnold: rml hace preempt
@Arador	sarnold: rml es el niñi bonito ;)
@Arador	sarnold:  y deva jons, no estoy muy seguro :) creo decordar x86-64, drivers de video...davej?
@Arador	davej: lo que sea en cada tiempo 8)
@Arador	sarnold: ( y como nota, ambos mochl y rml son los niñis bonitos :)
@Arador	rml: no te olvides de akpm, que es conocido por hacer todo unas veces o otras
@Arador	davej en el ultimo año  eh cuiero muchos areas al portar cosas desde el 2.4 al 2.5, algunas cosas de x86-64, y ahora mismo estoy en agpgart
@Arador	sarnold: desarrollo/comunidad?
@Arador	davej: sin duda, todavia recuerdo que akpm es un alias para una sala llena de hackers 8)
@Arador	rml: jaja...el aprendio a hacerse for() a si mismo como Alan
@Arador	fork()
@Arador	sarnlod: rml, algo que perdistes mientras te reconectabas....
@Arador	akpm mi secreto es evitar los drivers ;)
@runlevel0	<rml> OK, suficiente sobre nosotros mismo - aparte de mochel y su historia belicas sobre vietnam no somos  interesante.. siguiente pregunta?
@runlevel0	<rml> akpm: no mantenías los drivers de red? :)
@runlevel0	<sarnold> mentionaste unificación de VM e IO  de bloque..
@runlevel0	<sarnold> ¿que tal funcionaria eso con vendedores de bases de datos que tipicamente quieren hacer funcioanr toda la maquina como si fueran el propio SO?
@runlevel0	<andre> Una de las preguntas que tengo para la gente de aquí es que yo trabajo en el asunto de limpiar la zona gris de trabajos derivados y pristinos para que mas gente use Linux en la empresa  y no tenga que
@runlevel0	* gregkh siempre se escapa de la pregunta de andre
@runlevel0	*andre espera que lo echen ahora del canal
@runlevel0	akpm rml: si eso es casi el casom pero no gasto casi tiempo en drivers ahora mismo
@runlevel0	<rml> sarnold: O_DIRECT o raw/IO y estad contentos, Creo... que pueden evitarse un buen trozo del kernel si qeren
@runlevel0	<gregkh> andre: somos desarrolladores, no abogados, por favor aquí no
@runlevel0	<andre> OK
@runlevel0	<rml> solo quietiones tecnologicas
@runlevel0	davej> <ShawnWerk> (*cough* PnP)
@runlevel0	<akpm> sarnold: las bases de datos grandes tienden a invadir toda la máquina. Se intenta evitar usarlas o hacerse dependientes de VM o incluso sistemas de ficheros
@runlevel0	<davej> todo el asunto Pnp ha sido puesto al día bastante
@runlevel0	<sarnold> una cosa de la que me he dado cuenta, es que gente como rml (robert love) trabajan sobre todo en asuntos de respuesta de los desktops, como kernel preemtivo (para bajar la latencia)....
@runlevel0	<akpm> sarnold: para bases de datos la ES directa es un asunto critico y cosas como pagians tlb grandes, paginacion compartida
@runlevel0	rml> ... y e lscheduler
@runlevel0	<davej> shawn: No creo que haya documentación especifica de que ha cambiado
@horacio	sarnold: y otra gente, como wli (wiliam lee irwin) está mayormente interesada en grandes sistemas, donde el troughput tiende a ser un objetivo dominante
@runlevel0	<sarnold> y otra gente, como wli (william lee irwin) estan mas interesados en sistemas grandes, donde la velocidad tiende  ser la meta dominanate
@horacio	sarnold:  hay un medio feliz entre respuesta y el rendimiento total en el kernel 2.5? ¿Como se compara con el 2.4?
@horacio	davej gregkh: has metido el pnp un poco mas?
@horacio	rml: eh, buena pregunta. Es un pendiente.
@horacio	andre: uno de los cambios en bloque mas fuertes ultimamente proviene de Oracle, superbh
@horacio	akpm sarnold: 2.5 esta mucho más afinado para la velocidad de respuesta. A menudo eso significa una mejora en el throughtput. Pero a veces no.
@horacio	gregkh ShawnWerk: si, la capa pnp ha cambiado mucho, pero lamentablemente, no hay documentacion que yo conozca.
@horacio	sarnold andré: te ocupas de elaborarla superbh?
@horacio	andre: es una manera de dirigir 10% de pedidos io en un lote, y volcar el exedente bh en 2.4 por ab
@horacio	andre: en lugar de preocuparse por simples eventos sector/por-esperar, puedes lotear efectivamente una liste de iovecs a un bloque y dejarlo correr
@horacio	davej; ShawnWerk: portar pm de 2.4 ha estado en mi lista por un tiempo. Intencionalmente lo he dejado unos meses atrás, y aún tiene algunos problemas
@horacio	sarnold andre: hay alguna relación entre superbh y el asynchronus IO de benjamin?
@horacio	andre: no que yo pueda decir, uno es un proceso de envío y el último es un proceso de ejecución
@horacio	davej ShawnWerk: no estoy seguro, Tengo que jugar con él para asegurarme.
@horacio	sarnold: un tema que veo particularmente frustrante es la necesidad de los  usuarios del alto rendimiento total y alta respuesta, esto es lo nuevo 0(1) en planeamiento . . .
@raul	ShawnWerk: usando la api de pci_dirver?
@raul	<sarnold> que problemas acarrea el planificador 0(1)para los usuarios interactivos, que problemas tiene para los usuarios de alto rendimiento total, y que piensas que puede hacerse para ayudar en esto?
@raul	<akpm> sarnold: No creo que eso este necesariamente relacionado. No en los sistemas de un solo procesador.
@raul	<akpm> sarnold: el planificador ofrece mejoras en escalabilidad, y esto conlleva mejoras en la "interactividad".
@raul	<akpm> sarnold: esto es la mejora de la interactividad que todavia no esta trabajada del todo.
@raul	<rml> Unix tradicionalmente siempre favorecio la interactividad sobre el rendimiento total en el planificador.
@raul	<zwane> akpm: creo que tu no eres un fan de algo como kautotuned con lo que se puede ajustar varios parametros del kernel segun el estado del sistema muestreado, hay alguna razno para la aversion ahceia este medodo?
@Arador	sarnold: akpm: creo recordar que los procesos de tiempo real (SCHED_RR, SCHED_FIFO) tienen gran latencia con el temporizador O(1) de Ingo, son problemas asociados con las majoras de interactividad?
@Arador	rml: sarnold: no, las tareas de tiempo real no estan afectadas por el estimador de interactividad. Son clases con "prioridad estatica"
@Arador	rml: mas alla, las tareas que no son de tiempo real  no pueden ver ioncremetnada la prioridad a la prioridad de una de tiempo real por el estimador de interactividad
@Arador	akpm: zwane: lo que menos me gusta de eso es que se equivocara cuando el sistema cambie repentinamente de carga
@Arador	rml: la unica regresion de tiempo real que conozco es en SMP. Como tenemos listas de procesos para ejecutar por-cada-CPU, es posible que una tarea de tiempo real se paralize en un procesador cuando otro puede ejecutarla
@Arador	sarnold: rml hay regresiones en el resto de la serie 2.5? hay algo que iba mejor en el 2.4?
@Arador	rml: sarnold akpm estaba mirando algunos...
@Arador	zwane: akpm: mmmm, sin duda eso no funcionaria para cambios en tiempo real y por lo tantos mas adaptativos pero hacemos malas decisiones  ahora de todas maneras
@Arador	Bachhus: sarnold: esas regresiones son normales durante el periodo de desarrollo
@Arador	rml: la mayoria de las cosas son mejoras (sin embargo leves) aunque podriamos comprometer la entrada/salida en algunos casos
@Arador	andre: <mas> Hola, querria saber como panelar? la idea sobre el entorno de computerizacion autentificato MSFT's que significa basicamente (para mi com programados) el hardware no se ejecutara el software no autorizado en MSFT's? En esos terminos afectara a Linux y a la comunidad de desarrollo por ello?
@Arador	rml: pero akpm puede hablar sobre sus descubrimientos recientes en 2.5 de regresiones?
@Arador	zwane: rml: no es posible hacer una migracion? o seria demasiado caro?
@Arador	Bacchus: sarnold hay un monto de ajustamientos en la fas final del 2.6 para afinar correctamente las cosas
@Arador	andre: es similar a nuestro proceso de "tainting", lo usamos para determinar si es un kernel autorizado enterlo o un monstruo de codigo binario cerrado
@Arador	rml: zwane: probablemente lo es...podriamos hacer algo para al menos asegurar que las tareas tde tiempo deal estan bien distribuidas. La unica solucion perfeta es una lista de tareas global, como tenia el secheduler O(1) al rpincipio
@Arador	sarnold: akpm hay algo sobre lo que los usuairos de 2.5 se quejaran comparado con 2.4?
@Arador	andre: gregkh y manfred pueden responder mejor a esa cuestion
@Arador	akpm: sarnold: no realmente. Hay cosas que van mas despacio, pero muy poco. Los peores son los debidos a la adiccion de la VM rmap
@Arador	akpm: sarnold:  para algunas  cargas que hace mucho forks (por ejemplo, scripts de shell) puede ser hasta un 10% mas lento
@Arador	creo rellamar que daniel philips hablo sobre tablas de paginas copia-en-escritura, se ha hecho algun esfuerzo para este problema?
@Arador	akpm: Creo que podriamos arreglarlo con el codigo de comparticion de tablas de paginas. TOdavia lo estoy pensando
@Arador	akpm: sarnold: si, eso eso es en lo que estamos trabajando ahora. Pero para el caso de shell scripts, todas las tablas de paginas se escriben y copian de todas maneras :(
@Arador	sarnold: akpm: heh :)
@Arador	akpm asique me estoy preguntando si cambiar las binutils para dejar las direcciones virtuales del espacio de usuario fuera, para prevenirlo
@Arador	sarnold:  akpm: eso envolveria un monton de aleatoriedad o analisis de la libc y mapeados de programas, no? Tambien causaria demasiados vaciados de la TBL?
@Arador	gregkh: sobre la cuestion de msft, no puedo decir nada excepto que la gente esta mirando en como afectara a linux, y como se ejecutara linux en dicho hardware
@Arador	akpm: sarnold: podria requerir una entrada adicional de tabla. Probablmenete no es muy significativo....
@horacio	davej: *cough* Linuxbios *cough*
@horacio	sarnold davej: un problema que me he imaginado linuxbios tendrá es la confiabilidad en una placa madre específica; hay diseño de hardware com linuxbios, o algún otro proyecto opensource de bios, que pueda ser mas general?
@horacio	davej sarnold: desde donde puedo ver depende de saber un montón de cosas específicas (como el banco dram está cableado p.ej.)
@horacio	cdub_ mas: hay algunas implicaciones atemorizantes de TCPA y código abierto. también alegaciones de que es un esfuerzo de DRM con otro nombre
@horacio	sarnold <Phantom> porqué no está incluido IPSec en el kernel aún? ( o lo está en el 2.5?)
@horacio	rml Phantom: está en el nuevo 2.5
@horacio	hubieron algunos temas iniciales con la criptografía en el keren, que tuvieron que ser resueltos.
@horacio	davej http://lartc.org/howto/lartc.ipsec.html es un mini-howto para hacerlo  funcionar ....
@horacio	sarnold rml: saber si funciona con las utilidades FreeS/WAN,como los demonios de  negociación de llaves?
@horacio	rml luego los mantenedore de red tienen alguna calidad en el tema de probar el código, y querian hacer un monton en muchas formas.. por lo que tenemos algunas nuevas implementaciones en 2.5
@horacio	davej sarnold: usa una bifurcación de las utilidades KAME
@horacio	rml: de hecho, tenemos una capa de criptografía completa en el kernel ahora
@horacio	sarnold (de hecho, james morris, uno de los autores de la capa de criptografía, hizo una presentación de ello algunos dias atrás para umeet :)  )
@raul	* davej se da cuenta de que Alexey movio la ubicacione de las utilidades, y va a actualizar el documento de despues de halloween.
@raul	<sarnold> /de echo, james morris, uno de los autores de la capa de encriptacion, hizo una presentacion unos dias atras en umeet :)
@raul	<andre> rml: desde siempre esto ha ido haciendose modular, con ipsec debe tambien decidirse si lo hacemos suave o enganchamos y redireccionamos hacia el offload en las tarjetas de red.
@raul	<sarnold> como los temas noamigables para el usuario final; alguien pregunto si supermount seria incluido en la rama principal del kernel eventualmente, otro pregunto si oopse en el montaje de CDROMs podria ser menos facil...
@raul	<rml> No creo que veamos supermount
@raul	<rml> creo que oopses en el montaje de dispositivos seria mejor tomarlo como un driver tomarlo mejor.. esperando que hagamos algunos progresos. oopses siempre es bueno.
@raul	* davej se da cuenta de que Alexey movio la ubicacione de las utilidades, y va a actualizar el documento de despues de halloween.
@raul	<sarnold> /de echo, james morris, uno de los autores de la capa de encriptacion, hizo una presentacion unos dias atras en umeet :)
@raul	<andre> rml: desde siempre esto ha ido haciendose modular, con ipsec debe tambien decidirse si lo hacemos suave o enganchamos y redireccionamos hacia el offload en las tarjetas de red.
@raul	<sarnold> como los temas noamigables para el usuario final; alguien pregunto si supermount seria incluido en la rama principal del kernel eventualmente, otro pregunto si oopse en el montaje de CDROMs podria ser menos facil...
@raul	<rml> No creo que veamos supermount
@raul	<rml> creo que oopses en el montaje de dispositivos seria mejor tomarlo como un driver tomarlo mejor.. esperando que hagamos algunos progresos. oopses siempre es bueno.
@raul	<rml> arashi pregunto: como esta iendo el I/O asincrono? he oido que sera "antes del 2.6" en la lista de Guillaume
@raul	<rml> AIO esta ya
@raul	<sarnold> rml, pero supermount y devfs parecen ser populares entre al menos algunos usuarios; cual es el criterio utiliado para decidir que caracteristicas se añaden dentro?
@raul	<rml> sarnold: creoque supermount "no es lo suficientemente popular" todavia porque no es todavia totalmente elegante.
@raul	<davej> Juan Quintela invirtio un monton de tiempo en el ultimo año limpiando supermount, y todavia necesita un monton de trabajo por lo que escuche antes de que lo cogiera viro.
@raul	<rml> si, creo que es un largo obtaculo, Al Viro es el que mantiene para este subsistema y sus estandares son muy muy altos
@raul	<davej> Alan tiene un trabajo similar a hackear usando NFS sobre loopback o algo igual de retorcido.
@raul	<rml> No me gustaria ser el compañero que enviara supermount a Viro
@raul	<davej> ISTR que es todo el espacio de usuario tambien, que es bonito 8)
@cha0z	<sarnold> <mulix> piensan de la variedad de arboles del nucleo de tener ultimamente? no ayuda a los planes de la dominacion de el mundo.
@cha0z	sarnold: a mi me gusta añadir, El Mundo de la dominacion incluso un plan digno de persuing?
@cha0z	sarnold: davej: buena idea xD
@cha0z	akpm: sarnold: yo pieso que que los UL y RH tiene los árboles han divergido también lejos de mainline. Debemos trabajar mas dificilmente para conseguir cambios retroactuados.
@cha0z	rml: Pienso árboles externos del núcleo soy muy importante y útil cuando el árbol es mantenido por un revelador y él está utilizando el árbol tiene un testbed y sostener de tierra para que los remiendos alimenten a la corriente principal
@cha0z	akpm: sarnold: no pienso que cause algun problema serio.
@cha0z	zwane: mulix: la mayoría de los árboles ahora están para combinar propósitos y no principalmente las bifurcaciones
@cha0z	rml: me gusta 2.5-mm  y 2.5-dj son muy importantes.
@cha0z	sarnold: akpm: tu piensas que RH's y UL's el nucleo este obligado a cambiar de vuelta por  mainstream? marcelo la fusión de la lata solamente tan rápidamente y todavía llama 2,4 un núcleo estable.
@cha0z	akpm: sarnold: los bugfixes bien deben volverse al marcelo rápidamente. Las características son menos importantes.
@cha0z	akpm: sarnold: aunque podría ser el caso que no hay muchos unmerged bugfixes. No seguro.
@cha0z	akpm: sarnold: pero el tamaño de los diffs es poco el apenarse.
@horacio	rml: leí que UL tiene alrededor de 800 parches.
@horacio	eso necesita terminarse
@horacio	akmp: y yo debo atender una cita, lo siento . . .
@horacio	sarnold akpm: gracias por tu tiempo :) que tengas un buen fin de semana.
@horacio	davej rml: *nod* aunque un montón de lo de UL no vea nunca la línea principal, o se porte hacia atras en las características de 2.5  8)
@horacio	sarnold: una cuestión similar, <Lovechild> hay algún plan para conjugar Reiser4 pronto?
@horacio	rml Lovechild: esa es una decisión puramente concerniente a Linux
@horacio	davej: reiser4 es un montón de código, (cerca de 2Mb iirc)
@horacio	rml: pienso que si si tiene cero o mínimo impacto para el código que no es específico de reiser4, se hará.
@horacio	davej: eso es mucho código para un sistema de archivos.
@horacio	rml pero tengo el presentimiento de que pueda ser intrusivo... como davej dijo, 2Mb es mucho código para un sistema de archivos
@horacio	rml: es muy tarde para agregar cualquier cosa intrusiva, y espero que Linus no se esfuerce en ello.
@horacio	davej: hubieron partes solo iirc 3 que se tocaron fuera de fs/reiser2, y viro, hch etc no tienen ninguna objeción que yo recuerde
@horacio	davej: así que es un puede ser.
@horacio	rml: Hm, bien.
@horacio	rml: pregunta: piensas que la clase de mejoras hechas dentro del kernel en el último ciclo de desarrollo añadirá demasiada complejidad como para asustar a un hacker del kernel novato? O de otro modo las nuevas APIs lo hacen más simple y accesible?
@horacio	rml: esta es una buena pregunta
@runlevel0	<rml> Linux siempre ha sido de diseño tan facil que era increible
@runlevel0	<davej> eso lo consiguió Larry McVoy durante el OLS/Kernel Summit.  En estos días las cosas son mucho mas complejas que cuando muchos comenzamos.
@runlevel0	<rml> yep, la barrera para entrar es mucho más alta
@runlevel0	<rml> para responder específicamente a la pregunta; es más alta, no hay duda, Pero espero que no lo suficiente para asusatar a os nuevos.
@runlevel0	<cdub_> a l mismo tiempo se ha formalizado otro material y consolidad en una API más agradable.
@runlevel0	<davej> ShawnWerk: desarrollo -> congelación de features -> congelación del código -> estabilidad.
@runlevel0	<davej> ShawnWerk: entre features y congelación del código las APIs  podrían cambiar si fuera absolutamente necesario
@runlevel0	<sarnold> davej: ¿tiene Linux planes para congelar pronto el código? ¿son realistas?
@runlevel0	<rml>nadie debe pensar que el desarrollo del kernel o el diseño dfe SO es fácil, pero la complejidad no necestia ser alta
@runlevel0	<davej> sarnold: no recuerdo haberlo oido poner fechas
@runlevel0	<rml> pienso que los buenos programadores con un buen conocimiento de teoria de SSOO pueden aun entrar de cero en el asunto
@runlevel0	<rml> davej: Creo que dijo el primero enero en ese crucero que estaba haciendo ;)
@runlevel0	<davej> rml: *shrug* no conseguí ir 8-)
@runlevel0	<rml> davej: NI YO :> pero lei que dijo que el primero de enero congelación y verano del 2003 para el lanzamiento.
@runlevel0	<rml> lo cual creo que es factible
@runlevel0	<sarnold> funcionaría un congelamiento de los trabajos en el modelo de desarrollo de linux?
@runlevel0	<rml> depende de lo que la gente se quede al pié del cañón
@runlevel0	<rml> sarnold: siempre tenemos una congelación al final de las series de desarrollo
@runlevel0	<davej> sarnold: depende. existe "Congelación de código" y "Congelación Torvalds de código"
@runlevel0	<rml> para varios grados de congelacion, por supuesto
@runlevel0	<davej> lo que es mas un "escarchado" que una congelación 8)
@runlevel0	<sarnold> hehe :) mi principal preocupacion es; si los desarrolladores trabajan principalmente en su propio árbol ¿notarían los errores en el kernel "congelado?
@runlevel0	<rml> Linus ha dicho que está "muy contento" con el 2.5. así que si no aparecen esquinas malvadas o regresiones, pienso que Linus
@runlevel0	<andre> rml: bien, para ser sinceros Viro es un tio majo que no acepta basura
@runlevel0	<davej> ahora mismo el mayor retraso del 2.6 lo constituyen un monton de drivers aun rotos de mala manera
@runlevel0	* sarnold guiña a  gregkh
@runlevel0	<cdub_> heh
@runlevel0	<rml> andre: nada de lo que dije quería ser negativo para con viro. Es un programador increible con un gusto muy fuerte. Sólo dije que era muy duro para aceptar parches
@runlevel0	<rml> lo que es una cosa realmente buena
@runlevel0	<sarnold> davej: se dejará fuera el codigo de los drivers de la congelacion?
@runlevel0	<andre> para poder ser readmitido en la lista de mantenedores tuve que mandarle codigo a Vrio i esa fue la prueba para ver si podía conseguir la hazaña de nuevo
@runlevel0	<davej> sarnold:  alguno de ellos estaba tan roto que se ha tenido que dejar
@runlevel0	<gregkh> sarnold: los drivers USB no estan rotos, es SCSI y lo relativo a layers de bloques
@runlevel0	<andre> rml: y por una malditamente buena razón, si todos tuvierasmos esa intolerancia hacia la chapuza, bueno...
@runlevel0	<davej> y mierda rara como
@runlevel0	<rml> andre: es verdad
@runlevel0	<andre> el scsi necesita un veradadero replanteamineto
@runlevel0	<cdub_> < will-h:#qc> ¿cuales son los cambios con md y LVM en el 2.5? ¿alguine quier resumir?
@runlevel0	<cdub_> creo que esa pregunta se perdió, greghk ¿querrías comentar los cambios en el dm?
@runlevel0	<andre> se necesita probar y modelar la lógica difusa de  máquinas de estado efectivas  en las operaciones con el bus
@runlevel0	<gregkh> dm ha rteemplazado el codigo LVM
@runlevel0	<gregkh> lvm2 y evms serán en su mayor parte codigo de espacio de usuario que usara el codigo dm del kernel
@runlevel0	<andre> esto volvería a meter toda la locura de vuelta a los drivers HBA y expoer finalmente el quien y el como de la fealdad del diseño de ahrdware "el fin justifica los medios"·tipo  de los grupos SCSI T10
@Arador	gregkh: will-h: ayuda eso?
@Arador	Bacchus: davej por lo que respecta a harmraido - Protesto :) He empezado a mantenerlo pero reparar el daño de varios años sin mantenimiento toma un tiempo...
@Arador	sarnold: andre: Siempre me he preguntado porque IDE y SCSI se manejan de diferentes subsistemas...no hacen lo mismo?
@Arador	davej: Bacchus: eres un hombre valiente 8)
@Arador	andre; hacerlo si, el como lo hace es mucho mas extraño de lo que te puedas imaginar
@Arador	sarnold: andre: te corroboro :)
@Arador	sarnold: en el tema de congelaciones de codigo, estabilidad, etc, esta preparado 2.5 para novatos para que lo prueben por si mismos? cual seria el mejhor metodo para probar 2.5 por nuevos usuarios?
@Arador	rml: Si, creo que 2.5 esta preparado para probadores eventuales
@Arador	andre: uno requiere un monto de cosas a mano (ATA/ATAPI) y el otro requiere un monton de fustracion (SCSI y derivados) para ponerse en las fases apropiadas
@Arador	davej: ugh, modulos
@Arador	gregkh: 2.5 funciona lo suficientemente bien para mi para usarlo en mi escritorio todo el dia
@Arador	rml: o si, probablemente los modulos sean un problema
@Arador	Paso la mayoria del dia cozando cosas relacionadas con modulos en agp. Aunque para ser sinceros a rusty, son todos por mi culpa
@Arador	rml: pero si puedes sobrevivir a eso ( o compilar estaticamente el kernel como los hackers del kernel reales <g> entonces estas bien
@Arador	davej: las cosas nuevas de los modulos hace cosas extra que las cosas viejas no hacian (como liberar las secciones __init)
@Arador	rml: Shawnwerk: pero los cambios de los modulos vinieron tan tarde
@Arador	rml: si, lo hicieron, quizas demasiado tarde
@Arador	davej: sin duda, muy tarde 8)
@Arador	gregkh: davej: lo hacen? no lo sabia, esta bien
@Arador	davej: gregkh: lo adivine de la manera dificil 8)
@Arador	* andre tiene que ir a la Cruz Roja porque tiene la sangre ? de la que se usa en los nacimientos en emergenci y recibio una llamada, adios
@Arador	rml: pero creo que lor probelmas en el nuevo codigo de modulos seran arregladas pronto
@Arador	davej: he estado queriendo añadir envenenamiento a la liberacion de __init por un tiempo
@Arador	rml: bueno, eso es aleatori, andre :)
@Arador	sarnold: andre: gracias por tu tiempo :) que tengas un fin de semana
@Arador	sarnold: zadeh y mave estan preguntando sobre el compilador C de Intel y gcc 3.2..
@Arador	rml: Mave: sera gcc 3.2 soportado pronto?
@Arador	rml: creo que ya lo esta
@Arador	rml: SOlo los viejos "pedos" como akpm que renuncian a dejar egcs no estan usando gcc 2.95 o ruperior :)
@Arador	rml: No tengo problemas con gcc 3.2
@Arador	davej: Creo que si la gente reporta bugs y usaron el conmpilador intel, se les pedira que usen gcc y repitan el bug
@Arador	davej: radial: antes de liberar memoria, memsetearlo con instrucciones ilegales. Si entonces conseguimos un ooops, esa regla se presenta
@Arador	BACCHUS: rml: EL mismo compilador se ha enlentecido continuamente desde egcs 1.1 que es tambien por lo que yo tambien me mantengo en el
@Arador	sarnold: davej: hay demasiados asuntos en el kernel de linux que l hagan estar atado tan fuertemente a gcc?
@Arador	davej: sarnold: no mios 8)
@Arador	rml: Bacchus: Si, es tremendamente lento, ahora. Eso es por lo que akpm no cambia
@Arador	davej: radical:  haria oops cuando alguien mas intentara saltar a esa memoria
@Arador	davej: radical : por ahora lo evitamos saltando a las secciones __init despues de liberarlo mayormente, porque la ram no ha sido reservada asique todavia contiene el codigo viejo
@Arador	zwane: davej: hay un monton de tablas de indentificacion de dispositivos marcadas como __init ;)
@Arador	sarnold: alguien tiene planes de actualizar la documentacion durante ela congelacion del codigo que podria ocurrir o no el 1 de enero? :)
@Arador	davej: zwane: suena como una entrada para Greg y hotplug...
@Arador	davej: RAist: Tux ha sido la pega para Ingo  mientras hacia cosas de threads
@Arador	cdub: radical: estoy trabajando en la documentacion de red del lkdp (el proyecto kernel linux doc-n) y usando 2.4.18/19 para ello. Ha sufrido muchos cambios el codigo de red en 2.5?
@Arador	davej: Raist: hay rumores de que lo ha intentado enviar para el 2.5 pero la congelacion ocurrio primero
@Arador	sarnold:  Shawnwerk: davej: esta los nuevos threads en 2.5 o en un arbol secundario?
@Arador	cdub_: bueno, hay cosas nuevas ahi. Como el ipsec. Tambien fuincionan llas rutas estakacbles (stackable)
@Arador	davej: Shawnwerk: esta todo en la linea principal. Necesitas nuevas glibc/ntpl para tener ventajas reales
@Arador	rml: Shawnwerk: todo el codigo de threads esta en 2.5 ahora
@Arador	rml: y los bits de glibc como los de NTPL estan en glibc 2.3
@Arador	aunque no se compilan por defecto
@Arador	rml: radical pregunto: que es exactamente el scheduler O(1)
@Arador	davej: algunas de las mejoras tambien benefician al espacio de usuario existente relacionado con threads
@Arador	rml: radical: es un temporizador de procesos, hace el trabajo de decidir que procesos ejecutar luego
@Arador	davej: Ingo escribio un buen sumario de esos en  http://www.codemonkey.org.uk/post-halloween-2.5.txt
@Arador	cdub: radical: pero no ha diseños/cambios grandes? Solo limpiezas, optimizaciones...etc?
@Arador	cdub_ radical: eso es lo que recuerdo en mi cabeza. Algunos dicen que la parte de red esta un poco por adelante de las toras partes del kernel ;-)
@Arador	rml: radical: hace esto implementando un mapa de bits de prioridades, asique sabe cual es el siguiente proceso ejecutable con mayor prioridad simplemente mirando al primer bit del mapa de bits
@Arador	davej: cdub: NAPI?
@Arador	cdub_: davej: bien, esto tambien esta en 2.4, no?
@Arador	rml: radical: asique no necesita escanear todos los procesos para entontrar el mas necesitado
@Arador	davej: cdub. perdi la pista. Estaba dentro, entonces se quito, y encotnes alguien dijo que habia vuelto...
@Arador	rml: radical: ese es la parte central, pero hay un monton de algorritmos mas, y son todos O(1) tambien....mucho que discutir
@Arador	cdub_: je, vale
@Arador	cdub_: radical: es posible que pudieras apuntar NAPI como tora actualizacion
@Arador	davej: Shawnwerk: el enredo de apg en la linea principal fue mi cupla...deberia estar bien cuando Linus vuelva a coger
@Arador	sarnold: El soporte de threads NTPL esta para ayudar a soportar los threads POSIX; esta convergiendo Linux hacia un suporte completo de POSIX, o alguna de sus especificaciones?
@Arador	o Single Unix Especification? (especificacion unica de unix)?
@Arador	davej: Shawnwerk: aunque no deberia haber causado cuelgues, es como un problema especifico de DRm en vez de agpgart
@Arador	cdub_: creo que las ebtables est an dentro tambien
@Arador	sarnold: ebtables?
@Arador	cdub_ netfilter para bridging
@Arador	rml: sarnold: solo donde pensemos que el estandar esta bien
@Arador	rml: sarnold: NTPL trata mas de rendimiento que cumplimiento, aunque estira el cumpllimiento en algunos areas
@Arador	sarnold: radical: bueno, la prueba de drivers podria hacerse mejor en vmware, pero añadir debuggers a uml es facil
@Arador	sarnold: al menos que no haya otros asuntos de "tecnologia" para discutir, creo que nos deberiamos mover a cuestiones filosoficas en este punto...
@Arador	davej: filosoficas? deberia traer cerveza?
@Arador	cdub_: si un kernel oopsea en una sucia esquina de un centro de datos donde puedas verlo, realmente oopsea?
@Arador	sarnold: davej menciono antes que parte del codigo de IPSec esta tomado del proyecto KAME...
@Arador	cuando esta compartido entre los campos de Linux y BSD, y deberia haber mas?
@Arador	davej: Personalmente ehcho un vistazo a que estan haciendo cada pocos meses en los areas que me interesan
@Arador	davej: algunas veces estan ellos adelante, algunas veces lo estamos nosotros, pero siempre es interesante
@Arador	davej: el trabajo en AGP que he hecho en 2.5 es similar al que freebsd ha tenido hace muchas lunas por ejemplo
@Arador	davej: por ejemplo, drivers por cada chipset en vez de una cosa monolitica
@Arador	davej: hable con los chicos de freebsd sobre su kjernel preemptivo (que estaba supuesto mas o menos para ser una cosa nueva en 2.5)
@Arador	Bacchus: en general, incluso cuando las incompatibilidades de licencias o otras cosas previenen de compartir el codigo nosotros y la gente de bsd nos hablamos los unos a los otros
@Arador	rml: sigo su trabajo en el temporizador, aunque se estan desviando un poco de cosas con las que estoy de acuerdo o cosas que la comunidad abarca (por ejemplo, KSE que son las clasicas "activaciones del scheduler")
@Arador	rml: pero sigo las cosas de BSD....creo que aprendimos un poco de su VM
@Arador	cdub_: si, pienso que es util, me gusta seguir a trustedbsd
@Arador	sarnold: que tal sobre Plan9? EROS? Windows?
@Arador	davej: no he tomado mucho tiempo en mirar a otros bsds, solo a freebsd
@Arador	savej: sarnold -ENOTIME 8)
@Arador	rml: No he mirado de verdad a Plan9 o EROS. Plan9 tienes algunas opciones de diseño interesantes
@Arador	rml: he leido algunos tests del diseño de Windows
@Arador	rml: incluso el kernel de NT deja mucho para desear, para ser honestos
@Arador	cdub_: c0nan: mmmm, algun plan de mecanismos de control de accesos basados en roles?
@Arador	rml: hacen algunas cosas grandes como prevenir la parada de procesos y la inversion de  prioridades
@runlevel0	cdub_> c0nan: si el proyecto lsm esta trabajando en un contro lde acceso generico
@runlevel0	<sarnold>rml: los spinlocks y semaforos de linux parecen estar diseñados para ser sencillos... ¿sufre Linux de terribles problemas por ello o representa la simplicidad también una ganacia en renidimiento?
@runlevel0	<rml> sarnold: especialmente en cuanto a los spinlocks representa una gran ganancia de rendimiento
@runlevel0	<rml> sarnold: no me gusta nada el locking inflado (p.ej: el de Solaris)
@runlevel0	<cdub_> c0nan: puede usarse para control de accesos basado en roles
@runlevel0	* cdub_ le pasa a  rml algunos turnstyles (?)
@runlevel0	<rml> cdub: eso es el mejor futuro para sus locks :)
@runlevel0	<cdub_> ;-)
@runlevel0	<cdub_> < c0nan:#qc> ¿Cual es el itinerario de ese mecanismo generico de control de acceso?
@runlevel0	<sarnold> la semana pasada Alan Cox dio una charla subrayando la importancia del tamaño del codigo y la cache; ¿existen esfuerzos para tratar de optimizar la implementacion de las estructuras de l kernel para que quepan en las lineas de cache?¿alguna prueba sistematiac de diferentes flags de optimización de los compliadores?
@runlevel0	<cdub_> el objeticvo primario es continuar la union con la linea principal
@runlevel0	<cdub_>esto incluye la consolidacion de las limpiezas. Luego meter algunos modulos mas.
@runlevel0	<rml> sarnold: Pienso que bastante, yah. Puede que demasiado uso de cache-line-aligning
@runlevel0	<rml> tenemos que mirar la huella en cache del 2.5, ya que seguramente es mayor
@runlevel0	<cdub_> sarnold: pienso que hay que tener ciudado con el exceso de optimizaciones apra los micros. Puede que no funcione en todas las arquitecturas.
@runlevel0	<sarnold> paremos un momento para dejarles algo de tiempo a los traductores para alcanzarnos ...
@runlevel0	<davej> rml: son todos esos preempt_enable()
@runlevel0	<davej> 's
@runlevel0	* davej se agacha
@runlevel0	<cdub_> sarnold: pero dcache bloqueando los cambios es un buen ejemplo de cambios algoritmicos para mejorar el "machacamiento" de la cache.
@runlevel0	* rml le tira una vieja sparcstation a  davej
@Arador	*rml tira una vieja estacion sparc a davej
@Arador	davej: necesitamos traductores preempt
@Arador	sarnold: Algo sobre lo que mulix pregunto, y me gustaria saber que libros recomendais leer?
@Arador	rml: para programar o para divertirse? :)
@Arador	cdub_ Je
@Arador	sarnold: rml, bueno, mulix pregunto especificamente sobre libros tecnicos, pero los dos podria ser divertidos ;)
@Arador	davej: me gustan los libros de mindshare
@Arador	rml: Para divertirse, se que a mochel le gustan esos libros de romances
@Arador	davej: rofl
@Arador	cdub: lol
@Arador	creo que "UNIX Systems for Modern Architectures" (sistemas unix para arquitecturas modernas) de Curt Schimmel es un libro excelente
@Arador	sarnold (aunque curt trabaja para SGI?)
@Arador	rml: seguro, es un buen libro
@Arador	davej: a pesar de que es un libro de Microsoft, he estado leyendo "escribiendo codigo solido" otra vez recientemente. Es un de mis favoritos, y sorprendentemente bien escrito
@Arador	Bacchus: Curt describe otras arquitecturas como i386
@Arador	cdub_: mulix: cualquier cosa de stevens siempre tiene cosas buenas (aunque, no sean directamente rlacionado con la programacion del ekrnel)
@Arador	rml: "UNIX Internals: The New Frontiers" (internalidades de UNIX: Las nuevas fornteras) de Vahalia es excelente, tambien
@Arador	davej: el libro de ia64 es otro bueno que todavia no ho terminado
@Arador	rml: habla sobre cosas como gestiones de memoras basados en mapeados inversos, preempet del kernel, optimizaciones SMP, etc...una coleccion de cosas avanadas de UNIX
@Arador	sarnold: Raist: Para un novato, es bueno empezar a trabajar con el ultimo kernel o con uno historico?
@Arador	davej: empeze con el que era la rama actual de desarrollo, y nunca cambie 8)
@Arador	rml: determinate y _lee_ y _escribe_ codigo
@Arador	Bacchus: Suelo recomendar kernels que esten bien documentados por la literatura disponible
@Arador	davej: Mientras que nu monton de libros que hay hai fuera se concentran en las versiones viejas, es el concepto lo que realmente tienes que entender
@Arador	davej: aunque entender el codigo tambien ayuda algunas veces 8)
@Arador	sarnold: davej: crees que el libro de bach cd 1984 (o 1986?) todavia es una buena introduccion?
@Arador	davej: titulo?
@Arador	rml: estoy leyendo ese libro ahora mismo
@Arador	akpm: rml tiene razon. Puedes escribir codigo todo el dia y no aprender nada. Es cuando necesitas empezar a aprender. Porque tienes que hacerlo
@Arador	*davej no tiene esperanzas con los nombres
@Arador	sarnold: davej: ...." Design of the UNix Operating System" (diseño del sistema operativo unix) creo...
@Arador	davej: sarnold: no lo he leido
@Arador	rml: davej: el viejo libro de SvR2
@Arador	davej: hay un monton de manuales viejos que nunca tengo tiempo para leer. Quizas deberia dedicarles un dia o dos de lectura cada mes 8)
@Arador	sarnold: buena idea!
@Arador	sarnold: hemos estado ya dos horas...asique me inclino a preguntar mas cosas, y entonces abrid  para todos para aquellos que todavia tengan tiempo ;)
@Arador	sarnold: mi ultima pregunta: trabajar en linux todavia es divertido? con las nuevas corporaciones gigantescas trabajr en linux es divertido como puede ser un hooby?
@Arador	gregkh: es mi trabajo y my aficion, y si no fuera mi trabajo todavia seria mi aficion
@Arador	rml: todavia es divertido. Creo que todos los que estamos aqui siendo pagados nos damos cuenta de lo afortunados que somos
@Arador	davej: Siempre dije que haria otra cosa el dia que dejara de ser divertido. Que te paguen por trabajar a tiempo completo es un bonus
@Arador	sarnold una mas antes de desmoderar #linux
@raul	<sarnold> mirad http://www.kernelnewbies.org para mas informacion :)
@raul	<sarnold> y con esto, me gustaria agradecer a akpm, andre, rml, davej, mochel, gregkh, cdub, bacchus por tomarse las molestias de hablar con nosotros durante estos dias :)
@raul	<sarnold> gracias tambien a nuestros traductores :)
@raul	<davej> gracias por invitarme 8)
@raul	<rml> muchas gracias :>
@raul	<c0nan> gracias a todos por esta bonita sesion! :)
@raul	------ fin
MJesus	clap clap clap clap clap clap clap clap clap clap
@MJesus	clap clap clap clap clap clap clap clap clap clap
@MJesus	clap clap clap clap clap clap clap clap clap clap
@sarnold	wow! :)
@MJesus	clap clap clap clap clap clap clap clap clap clap
@MJesus	clap clap clap clap clap clap clap clap clap clap
@MJesus	clap clap clap clap clap clap clap clap clap clap
@MJesus	clap clap clap clap clap clap clap clap clap clap
@sarnold	plas plas plas plas plas :)
slack	clap clap clap clap clap
@sarnold	you guys are animals :)
CSMan	clap 100x
Samael	plasssssssssssss plassssssss plasssssssssssss
Samael	plasssssssssssss plassssssss plasssssssssssss
Samael	plasssssssssssss plassssssss plasssssssssssss
Samael	plasssssssssssss plassssssss plasssssssssssss
Samael	URRAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Samael	ya tengo el log completo en español
Samael	mañana sale publicado en linux cuba d;)

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net!