Charlas 9-12-2000 Umeet'2000

Charlas 9/12/2000

Log de la conferencia. Se han suprimido las líneas correspondientes a entradas y salidas de diferentes personas en el canal durante la conferencia

[22:15] > 22:00 Conectiva Team: Guilherme Wünsch Manika,Elvis Pfutzenreuter,Andreas Hasenack,Arnaldo C.de Melo "Recent Developments in a Linux Based Operating System Time'
[22:15] (-) "Vamos a discutir un poco sobre el futuro de las distros de Linux, al mismo tiempo desde un sentido tecnico y la posicion que las companias Linuxeras tendran que adoptar"
[22:16] (|) acme es un fundador de conectiva y se mantiene como mantenedor de las versiones mas jovenes de conectiva linux
[22:16] (-) "acme: si, eso dicen ;-)"
[22:17] (|) andreas es el encargado de la seguridad, para que los hackerrs no entren
[22:17] (-) "a epx le gusta kde, sistemas de archivos remotos y otras cosas muy interesantes- el va a hablar sobre lo que hace y eso les va a resultar muy interesante"
[22:18] (|) gwm:y yo soy mantenedor y empaquetador
[22:18] (|) acme hablará de historia
[22:19] (-) ufff, estoy lagueado :P
[22:19] (|) #qc para preguntas generales y discusion, nosotros trataremos de respondeer a todas las pregundas sobre el topic
[22:19] (-) "acme: usamos linux para todas las cosas interesantes"
[22:19] (-) "acme: empezamos con slackware"
[22:20] (|) acme: ahora cualquiera pilla una distribucion por internet y el ingles no esta bien para todo el mundo ......
[22:21] (-) "rpm fue un gran avance"
[22:21] (-) acme: redhat no tenia lo que necesitabamos y empece a informarme sobre como hacer paquetes por mi cuenta
[22:21] (|) rh no tenia algunos de los paquetes que necesitabamos a si que aprendimos como iba empaquetar con rpm
[22:23] (|) pero queriamos hacerlo mas facil y los clientes querian cajas con todo lo que estabamos haciendo
[22:23] (-) desde ese punto empezamos a hacer mas modificaciones constantemente a redhat
[22:23] (|) entonces empezamos a colaborar con el software libre, haciendo patches, internacionalizando
[22:24] (-) y cryptografia que no estaba en las distros de los estados unidos
[22:24] (|) y desde entonces: entrenando, dando soporte ....
[22:25] (-) ahora somos una compania de linux y luchamos para hacer la mejor distro
[22:25] (|) mantenemos fieles al free software, haciendo todas nuestras modificaciones y nuevos programas accesibles por la comunidad
[22:26] (-) cosas com apt con rpm , controladores de video para XF86, mejoras a linuconf y nuevos modulos para hacer la configuracion mas facil
[22:27] (-) y les pagamos un salario de tiempo completo a hackers del kernel com rik van riel y marcelo tosatti
[22:27] (|) y estable para mas y mas gente sean capaces de usar todo este maravilloso software desarrollado cooperativamente
[22:28] (-) soportando el desarrollo en la "alta disponibilidad" , arreglando el kernel. Bueno creo que hemos hablado suficente, no? :)
[22:28] (|) desarrollando alta disponibilidad, arreglando drivers del kernel etc
[22:28] (|) jode
[22:29] (-) si alguien tiene preguntas que las haga en #qc
[22:29] (|) epx: hablare sobre algunas cosas del escritorio de linux, kde2 servidores de sonido , cups, y sobre el esquema de inicio del sistema
[22:29] (|) linux en el desktop es un gran tema estos dias
[22:31] (-) es muy bueno en el mercado de los servers , pero la adopcion en el escritorio esta creciendo mas lentamente comparado con lo que cierta gente esperaba
[22:31] (|) epx:lo mas importante cuestion es el estandar en el entorno de escritorio
[22:32] (-) la mayoria de la gente tecnica usa algun administrador de ventanas (ej window maker =) ) pero para largar linux a la gente normal algo mas elaborado se requiere
[22:34] (|) epx: kde y gnome son los entornos que mas cercanos estan en ofrecer tal amigabilidad al usuario. hablare mas sobre kde pero muchos de los avances son iguales para gnome
[22:35] (-) primero, una obvia es una interfaz estandard constante con los usuarios
[22:35] (|) epx: segundo no tan obvio, un api/ambiente standar para las aplicaciones, porque dejar al programador con X y POSIX solo hacen desarrollar por ejemplo programas corporativos mucho mas dificil
[22:36] (-) la tercera es un arquitectura de componentes que permita el reuso de las partes graficas (el reciclaje de clases) como (KDE::Parts)
[22:39] (|) exp:asi la adopcion de linux en el desktop incluso en ambientes empresariales , donde hay cierto grado de soporte tecnico , y los usuarios no tienen que installar sus propios ordenadores etc. depende mucho del desarrollo de Kde y Gnome
[22:39] (-) otra cosa molesta sobre linux en el escritorio es el escaso soporte de impresoras
[22:40] (|) los demonios de impresora de BSD (como lpr LPRng) hacen su trabajo bien pro no son realmente hechos para usuarios
[22:40] (-) estan hechos para impresion en alto volumen (cantidad), ejemplo: si tienes una impresora con
[22:40] (-) nota personal:: cups hasta cierto punto soluciona esto
[22:40] (|) 3 posibles resoluciones, 2 modos economicos de tinta y 4 posibes tamaños de impresora tu podrias
[22:42] (-) terminar con 2*3*5=30 colas para solo una impresora, porque lpr no permite impresion en tiempo real
[22:42] (|) specificacion de ello. Sino escribes tu propio driver y metes comandos en los datos lo que es casi imposible
[22:43] (-) cups implementa el sistema de colas de una forma nueva y original, y la mas importante diferencia para el usuario final es:
[22:43] (|) s que la representacion de cada impresora es identica a las impresoras físicas
[22:44] (-) entonces cuando uno quiere imprimir algo el va a poder elegir la resolucion (definicion/calidad/puntos por pulgada) , el tipo de papel, etc....
[22:45] (|) y mas importante para los desarrolladores, nuestras aplicaciones pueden saber que es lo que el usuario quiere hacer. el sistema BSD no tiene nada cercano a esto y CUPS implementa esto in el protocolo/api principal.
[22:46] (|) incluso si cups es tan grando es un poco un poco malo si no lo adopta todo el mundo.
[22:46] (-) entonces creemos que cups es el futuro de la impresion en el ambito del escritorio y , nosotros conocemos es frase que dice "el que es duenio del escritorio,puede ser duenio de los servidores"
[22:46] (-) entonces cups puede:
[22:46] (|) bien capturar el mercado del sistema de impresion BSD tambien
[22:47] (|) una pregunta: cups no es libre,. teneis alianzas con empresas?
[22:47] (-) andreas: todabia faltann hacer algunos retoques a cups
[22:47] (|) el problema es que no hay drivers libres asi que cups y BSD coexistiran un tiempo
[22:48] (|) pero habra mejor soporte de drivers y aplicaciones con cups
[22:48] (-) andreas: pero falta mas soporte y controladores ,por supuesto
[22:49] (|) una ultima nota, cups prosenta una api stable para drivers tambien, veremos las compañias de impresoras distribuyendo drivers binarios en el futuro
[22:49] (-) epx: (bueno, los controladores binarios (sin codigo) son diabolicos, pero..... ;) )
[22:50] (|) ambos kde y gnome presentan un servidor de sonido, es un software que actua como un visor
[22:51] (-) la funcion mas importante de un servidor de sonido es la posiblidad de crear la opcion de mezclar las ondas (fuentes) . ejeplo: escuchas un mp3 pero
[22:51] (|) la funcion mas importante del servidor de sonido es crear la posibilidad de mezclar conductos de sonido, ejemplo estas reproduciendo un mp3 pero
[22:51] (|) ahh
[22:51] (-) ouch
[22:52] (-) ...quieres seguir teniendo la posibilidad de escuchar alertas del sistema
[22:52] (|) desde que el software multimedia/de sonido usan mas el chanal DSP, y menos el midi y el cdaudio
[22:53] (-) el servidor de sonido no es mas un juguete ... ES una necesidad
[22:53] (|) el gran asunto sobre servidores de sonido son las aplicaciones viejas, ellas intentan abrir /dev/dsp directamente .
[22:54] (-) no va a tratar de usar el servidor de sonido. Ambos, esound y arts (gnome y kde respectivamente)
[22:54] (|) tienen un apaño para permitir a esas aplicaciones hacer sonar el sonido via sound server, ambos patches usan
[22:55] (-) LD_PRELOAD cosas (meter una trampa en open(), close().....etc
[22:55] (|) apaño es no tan limpio y no funcionara en algunas aplicaciones
[22:55] (-) entonces vemos que todas las distros de linux luchan para que sus aplicaciones de sonido trabajen con estos servidors de sonido
[22:56] (|) Y parcheando las aplicaciones opensource (algunas no pueden ser parcheadas y son demasiado importante para ser ignoradas)
[22:57] (-) bueno, esas son las socas que el escritorio acarrea, preguntas podran ser hecas en #qc. Ahora vamos a hablar sobre los scripts de inicio
[22:57] (-) s/socas/cosas/ =)
[22:57] (|) todo el mundo reconoce que el estilo del sistema de inicio de System V tiene sus meritos pero necesita un cambio. En particular
[22:58] (-) creando relaciones de dependencia entre servicios , ejemplo si el usuario empieza algo que precisa de algun otro,
[22:58] (|) como NFS y portmap, lo ultimo empezará win intervencion explicita del usuario.
[22:59] (-) si, nfs necesita de red, red necesita pcmcia si pcmcia esta disponible
[22:59] (|) pero el usuario solo ve nfs, asi algo como "servicios de inicio arrancan nfs" deben empezar los otros
[23:00] (-) y si yo activo nfs para este nivel de ejecucion los otros tendrian que aparecer automagicamente
[23:00] (|) y tambien esta lo de paralelizar la execucion del los scripts de inicio que podria mejorar el arranque de la máquina
[23:03] (-) el asunto de la dependencia se trata de que el usuario no tenga que preocuparse por cada simple detalle y todo le sea solucionado automaticamente.
[23:03] (|) algunos han propuesto nuevos esquemas , lsb de Richar Gooch (linux boot scripts) es el mas conocido
[23:03] (|) los tres implementan arboles de dependencias, deteccion de bucles de dependencias y multiples hilos
[23:04] (-) mucha gente se enoja y protesta por la lentitud de la inicializacion de linux y tienen razon....
[23:04] (-) y muchos init scripts demandan espera, no cpu. no es asi?
[23:04] (|) y muchos arranques demandan espera no cpu
[23:05] (-) pero el multithread solo puede ser alcanzado si tenemos un arbol de dependencias, por eso estas dos cosas estan tan ligadas
[23:05] (|) no hay smb si no hay network
[23:06] (|) esquemas de gooch y clausen son algo completamente nuevo
[23:06] (-) estos dos esquemas no apuntan a la compatibilidad entre aplicaciones viejas y paquetes hechos para los script de un sistema System 5
[23:07] (|) nuestro esquema apuesta por la compatibilidad, asi funciona incluso si el admin instala cosas viejas
[23:07] (-) epx: el LinuxFilesytemStandard esta trabajando en esto tambien
[23:09] (|) todo el mundo sabe que todo tiene que cambiar y muchos procesos y arboles de dependencia deben entrar , prodemos esperar que las distribuciones adopten algun esqema en los proximoa meses
[23:09] (-) sin importar la conclusion a la que el LFS llegue yo creo que para nosotros el resultado va a ser muy favorable =)
[23:09] (|) vale, se acabo, hora de ir a #qc digo yo
[23:09] > 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[23:09] > 4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[23:09] > 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[23:09] > 4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[23:09] > 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[23:09] (|) APLAUSOS y VITORES VARIOS
[23:11] (-) como todos saben conectiva ha portado el deb apt get para que funcione con rpm =)
[23:11] (-) (apt get es lo que resulve las dependencias en debian, es milagroso algunos dicen)
[23:11] (|) apt era la cara mas comercial de debian
[23:11] (-) rpm tiene problemas, y algunos han sido mencinados en #qc
[23:13] (|) rpm es demasiado lioso y --force es usado demasiado a menudo
[23:14] (|) la legendaria calidad del empaquetamiento de Debian viene de un fuerte compromiso no politica
[23:14] (-) no es .deb que lo hace mejor, tiene cosas buenas y malas
[23:15] (|) hemos revisado hace poco nuestras practica spara hacer nuestra distribucion amigable a apt
[23:16] (-) notamos ciertas cosas mientras haciamos eso y antes de decidirnos por apt tubimos que trabajar en las diferencias que rpm tiene comparado con los paquetes deb
[23:16] (|) rpm tine algunas cosas que funcionan distintas a deb
[23:17] (-) por ejemplo han visto que rpm no sabe relacionar archivos especificos (librerias p.ej) con paquetes, no?
[23:17] (|) este tipo de dependencia (dependencia automatica la llamamos) es detectada mientras el paquete es generado, y funciona como paquetes virtuales
[23:18] (-) es en realidad un "proveee" que es aniadido al encabezado del rpm, esta es muy bueno para rpm en mi humilde opinion, pero es usualmente malentendido
[23:18] (|) estp es una gran característica de rpm en mi opinion pero es a menudo no entendida
[23:19] (|) no necesitas decir que windowsmaker depende de glibc , tiene que ver con lo practico que es generar paquetes que no romperan
[23:19] (-) cualquiera puede empezar su propia distro basada en debian pero hay muy pocas! por ejemplo corel
[23:20] (-) mucho del lio con rpm es culpa de que hay muchas distribuciones que lo usan
[23:20] (|) storm y progeny quieren compatibilidad con debian pero
[23:21] (|) por eso no son ejemplos de como funciona los rpm
[23:22] (-) algo en comun en relacion a paquetes son las auto dependencias y las dependecias basadas en archivos particulares, hasta que un stard oficial sea publicado
[23:22] (|) pero tenemos efectos negativos en los usuarios no saben de donde vienen las dependencias
[23:23] (|) el usuario tiene que pasar poor las dependencias de todas maneras
[23:23] (-) redhat y mandrake tienen la base de datos de rpms (rpmdb) que tiene dependencias, esto es parte del pasado y en realidad un feo embrollo, el usuario todabia tiene que arreglarse entre las dependencias por el mismo
[23:24] (-) eso no resulve el problema, "como mantengo mi sistema al dia?"
[23:24] (|) andreas tiene mucho trabajo que hacer para mantener la distribucion segura, pero el usuario todavia tiene que estar seguro de que el sistema es seguro
[23:25] (-) por eso tiene que ser simplificada la actualizacion del sistema, mantener la seguridad tiene que ser simple
[23:27] (|) el porte rpm apt incluye algo que apt no tenia , esta integrado en el arbol oficial
[23:27] (-) firmas digitales
[23:27] (-) dependemos de los espejos para mantenernos actualizados,, ni modo que nuestro ftp se banque el trafico
[23:27] (|) dependemos de mirrors para hacer nuestra distribucion accesible a los usuarios, de ningún modo nuestro sservidor ftp puede aguantar todo el trafico
[23:28] (-) ouch
[23:28] (|) asi con apt arreglamos muchas cosas
[23:28] (-) pero entonces estos espejos pueden ser hackeados por eso arreglamos apt para que circumvente esto
[23:29] (|) nuestros usuarios pueden mantener sus sistemas actualizados
[23:29] (-) 1. los usuarios no se meten con las dependencias
[23:29] (|) 2. nuestros usuarios pueden mantener sus sistemas actualizados
[23:29] (-) 3. paquetes que pueden ser confiados
[23:29] (|) 4. nuestros usuarios tienen una manera standard te hacer todo ello
[23:30] (-) podriamos haber hecho la nuestra y salir con un programita que solucionara esto solo para conectiva pero decidimos no hacerlo
[23:30] (|) apt estaba ahi, es bueno, es robusto, es estable, es bien conocido, se usa diariamente
[23:31] (|) apt es el mas importante herramienta de paquetes hoy
[23:32] (-) entonces haber ido por nuestra cuenta en un camino diferente hubiera sido tonto. quiza si las leyes de mercado hubieran mandado sobre nuestra compania hubieramos tenido ese programita pero este no es el caso ... hemos decidio marcar la diferencia en nuestra comunidad de linux
[23:33] (|) con rpm y deb tenemos a todo los usuarios
[23:33] (|) excepto slackware que lo tendrán pronto
[23:34] (-) ahora, esto es realmente importante. lei recientemente en algun lado que id soft no iba a hacer disponible la version linux de su ultimo quake para la venta en comercios
[23:34] (|) ellos usaran todavia un solo binario linuxquake sin soporte, pero eso no es lo que nosotros como usuarios de linux queremos
[23:35] (|) hay sin embarto un esfuerzo sincero de las distribuciones para cambiaar eso
[23:35] (-) al menos las mas serias, el LSB ha forzado la creacion de un estandard real que los ISV pueden confiar
[23:37] (|) algo en lo que confiar no como el "foo bar para redhat linux"
[23:38] (-) ahora el trabajo esta centralizado en hacer algo comun que permita diseniar tanto paquetes deb com rpm partiendo de la mism fuente
[23:38] (-) esto quiza sea un agregado a rpm v3 quiza
[23:38] (|) imaginaz instalar rpm en debian y viceversa
[23:38] (|) con apt se puede
[23:39] (-) imaginense poder instalar .debs en redhat y vice versa!
[23:39] (-) apt puede fomentar esto
[23:40] (|) con apt y rpm tenemos la 6º ventaja
[23:40] (-) 6. diferencias entre ambas han sido minimizadas
[23:41] (|) esto es muy improtante, alfredo kojima y jason Gunthorpe han escrito una proposicion para el subconjunto rpm que mencione
[23:41] (-) esto esta siendo analizado por el LSB y es lo mas importante sobre el tema hasta hoy, creo
[23:43] (-) RPM apt es genial y tiene mucho potencial, grandes cosas se podrian esperar de el
[23:43] (|) creo que ahora se entienden mejor algunos fallos de concepto sobre rpm y apt,
[23:43] (-) lo hemos estado usando para nuestra disto y nos ha hecho pensar de nuevo sobre ciertas cosas
[23:44] (|) on apt nuestrs paquetes tienen mas calidad que nunca, actualiza cuando quieras es algo que no existia antees ahora esta aqui
[23:44] (-) con el viejo modelo los usuarios compraban cds cada seis meses y actulizaban todo de una vez
[23:45] (-) pequenios problemas eran perdonados, pero nadie tiene que conformarse con eso....
[23:46] (-) debe ser posible actualizarlo sin mucha intervencion
[23:46] (|) debe ser posible actualizar tu sistema linux ahora sin tener que sentarte frente a tu ordenador mientras se hace
[23:46] (-) o la menor posible
[23:47] (|) elegimos la via opensource, asi trbaja la comunidad free software
[23:47] (-) por eso creemos que otras distro basadas en rpm pueden hacer lo mismo ahora
[23:47] (-) y adoptar apt
[23:47] (-) tubimos problemas de calidad y quiza ellos tambien los tendran...
[23:48] (|) se despertaran y oleral el napalm y se darancuenta que su sistema no es lo que los usuarios quieren o necesitan
[23:48] (|) rpm apt otra gran contribucion a la comunidad linux
[23:49] (-) 7) rpm apt traera mas calidad
[23:49] (-) (....a las otras distribuciones)
[23:50] (|) no se necesitaran atender a las actualizaciones si no es muy necesario. nunca mas se considerara aceptable que una actualizacion te rompa el sistema
[23:50] (|) no mas caza de dependencias
[23:50] (-) quiza es tiempo de responder preguntas?
[23:50] (-) (#qc)
[23:52] (-) "debian no incluye modo de remover las dependencias de los paquetes de tareas ... hay que hacerlo a mano, ustedes van a arreglar eso?"
[23:53] > yo quiero preguntar... ¿por que se incluyen grandes paquetes repetidos como kde y gnome si solo se puede usar uno?
[23:53] (-) "tarea" es un tipo especial de paquete, creo que me gusta el modo de debian
[23:53] (|) hemos adaptados los paquetes tarea como debian
[23:54] (-) MJesus: esto no es verdad
[23:55] (|) eso es fenomenal si el usuario quiere una instalaccion atendida
[23:55] (-) esta pregunta es tonta en mi humilde opinion (claviola), la libertad de eleccion es muy importante
[23:55] (|) MJesus: yo uso los dos
[23:55] (-) MJesus: mucha gente usa aplicaciones de kde y gnome al mismo tiempo
[23:56] (|) debian en el mundo comercial es el vigilante de las distribuciones comerciales
[23:57] (|) debian y tu distribucion favorita compiten por un hueco en el mercado.
[23:57] (|) debian tiene una buena calidad que todas las distribucioones deberian copiar
[23:59] (-) el asunto de los cambios de v3 de rpm no van a romper la compatibilidad
[23:59] (-) la estandarizacion cada dia es mas amplia
[00:00] (|) dependencias filesystem estaran cubierto por lsb, sistema de ficheros esta aqui FHS
[00:01] (|) parte de la estandarizacion vendra de que las empresas padre distribuidoras cambiaran su modelo de negocio
[00:01] (-) creo que parte de la estandarizacion va a ser debido a que las companias que copian una distro mas importante van a adoptar los cambioas
[00:01] (|) habra mucha mas cooperacion porque detras de las empresas esta aun la comunidad
[00:02] (-) hay mucha mas competicion entre distros de la que ustedes creen, muchas veces la gente se pelea sobre cual distro es mejor por ejemplo
[00:02] (|) detras de la gente de marketing hay tecticos como tu
[00:02] (-) pero el cambio real vendra cuando los de marketing no tomen lados como han hecho hasta ahora
[00:03] (-) con los bajos valores de las acciones es verdad que ninguna va a sobrevir solo porque mucha mas gente la utilise
[00:04] (-) con muchas distros convirtiendose en proveedoress de soporte va a haber poca incentiva para el cambio como ahora
[00:04] (-) hasta mandrake que era super comercial va a cambiar ese modelo de operacion
[00:04] (|) cuando las distribuidoras se convierten en empresas de soporte, no habra necesidad de acelerar las cosas como hoy , se haran las cosas para los clientes
[00:04] * t00R usa mandrake =)
[00:05] Pregunta: ¿Hacia k tipo de negocio camina el opensource?
[00:05] (|) este tipo de desarrollo es un paso adelante en la estandarizacion
[00:05] Es rentable el opensource
[00:05] (-) MJesus: ese comentario que claviola hizo no era con intenciones de insultarte ;-)
[00:06] (|) las cosas estan muy aceleradas ultimamente no lo estarán en el futuro
[00:08] (|) las presiones por todos lados las nuevas formas de hacer negocio......linux estara en servidores en desktops y en tu reloj
[00:08] (-) mmmm, no me responden..
[00:11] (|) han preguntado sobre las firmas digitales
[00:11] (|) apt maneja repositories no paquetes
[00:12] (|) un repository es una coleccion de paquetes con relacion entre ellos
[00:12] (|) hasta ahora solo se usaba md5sum para ver su estado
[00:13] (|) alguien se puede mener en el ftp, meter un troyano y arreglar el md5sum, y todo esta ok
[00:13] (-) rpm ha soportado la firma digital desde hace mucho ya....
[00:13] (|) rpm tiene firmas asi que meter un troyano es romper la firma
[00:13] (-) entonces el meter un trojano rompe la firma
[00:13] (|) pero apt no lo tiene
[00:13] (-) pero apt no maneja esto
[00:14] (-) pero eso no quiere decir que no soporte las firmas
[00:14] (-) lo hace mediante un archivo especial
[00:16] (|) hay un fichero que dice que paquetes tiene el repository y ese fichero es el que es firmado
[00:16] (-) entoces si alguien modificara el paquete tendri que modificar este fichero central que esta fuertemente custodidado con un firma
[00:16] (|) si alguien cambia algo tiene que cambiar md4sum
[00:17] (|) y entonces cambiar tambien el archivo firmado, por lo que se le detecta
[00:17] (-) primero antes de bajar paquetes se checkea el archivo este por eso es tan importante
[00:18] (-) ese es el modo de operacion de apt get
[00:18] (-) si el archivo ha sido modificado apt no sigue bajando cosas
[00:19] (|) si esta bien chequea md5sum
[00:19] (|) y lo demas
[00:19] (-) si todo esta bien, se checkea la lista de archivos y las baja si cambiaroon
[00:22] (|) todo el tema es confianza
[00:23] (|) tienes que ver si confias en el autor o noo , si lo investigas tu mismo
[00:23] (-) seguro
[00:24] (|) pregunta: hara conectiva un frontend grafico para apt?
[00:24] (|) esas cosas son un poco de debian todavia
[00:24] (|) estamos poortandolas y haciendo algo tambien
[00:36] (|) preguntan cuanto se tarda en hacer apt rpm y dicen que kojima hizo la base en 1 semana
[00:36] (|) y luego 2 o 3 meses quizás .....
[00:36] (|) kojima es un buen programador
[00:38] (-) "nuestros japoneses son mas creativos que los japoneses de otra gente" jajaja
[00:39] (-) jajaja
Y seguimos un buen rato más charlando...

Contact: