Dia del Usuario Ubuntu

El dia de ayer se realizo el 1er Dia del Usuario Ubuntu para Latinoamerica, charlas en canales IRC de Freenode, unas charlas de este tipo ya se han dado para los usuarios de habla Ingles, pero siendo el primero para los usuarios de habla castellana.  La fecha de estas charlas via chat con la participacion de expertos representantes de grupos u organizaciones del Software Libre bajo Ubuntu Linux y otras distribuciones, ya se mencionaba hace tiempo en los LoCo Team, Launchpad, canales irc de freenode, listmail, foros, blogs e incluso en twitter.  Luego de un completo dia de charlas a partir del dia de hoy comenzara a resonar en los blogs de tematica de Software Libre a lo ancho y largo del internet, las criticas favorables y desfavorables del dia de ayer 23.01.2010, Dia del Usuario Ubuntu, un dia dedicado al usuario de este sistema. Tengo mas cosas que decir favorables que negativas del dia de ayer, considerando que las charlas se llevaron tan bien planificado como se pensaria que fuese y seguro que todos los que estuvimos presente deseamos que este evento (mi primer evento de charlas via IRC en Freenode), se repita nuevamente, el 1ero pero No el ultimo “Dia del Usuario Ubuntu” para Latinoamerica, ya era hora.

Importante:

Tengase en cuenta que es normal que la Critica opine de un evento, donde se expresan criticas “constructivas” puntos favorables y/o desfavorables de un determinado suceso/evento, no desde un punto de vista de perjudicar sino de indicar fallos y animo de mejoras para perfeccionar/fortalecer esos puntos debiles para los futuros eventos. Indicare los niveles de exponencia en un marguen valorado del 1 al 10. Siendo del 1-4 en rojo, del 5-8 en amarillo y 9-10 en verde.

Practicamente llegue una hora antes de empezar las charlas, obviamente ya habia gente en los canales, este se realizaria en los canales irc de freenode ubuntu-charlas donde serian las charlas y en ubuntu-charlas-chat las preguntas dirigidas a los exponentes. El canal de las charlas estaba moderado (principalmente por los presentadores “Pablo Rubianes” y “Diego Turcios”) tambien como apoyo en los canales “Elián Hanisch” mejor conocido en los bajos fondos de freenode como m4v : )  incluso antes del inicio paso cjohnston uno de los encargados de este mismo evento pero para la comunidad de habla Ingles, ya que recordemos, se realizo en paralelo el mismo evento.

Sin perderme de nada con incluso 40 min de tiempo antes de empezar las charlas, como comento uno de los presentes, tiempo para aflojarse un poco la corbata : ) se pasaba ese tiempo aclarando dudas de como seria, teniendose en cuenta que era la primera vez que se organizaba algo como esto para Latinoamerica o usuarios de habla hispana, usuarios de Espana, Uruguay, Guatemala, Venezuela, Mexico, Colombia, Argentina, Brasil, etc llenando las butacas virtuales de la sala, ya los presentadores estaban en la tarima terminando los ultimos ajustes para dar inicio a la Presentacion/Introduccion  : )

Desde luego, la diferencia de horaro de cada pais/ciudad no indicaba con presicion la hora exacta de inicio del evento, esto se podia conocer por medio de la UTC donde se indicaba la hora acorde a tu ciudad. Faltando 10 min, luego 5, luego 2 empezo (a mi hora 11:30am) hora de Caracas, Venezuela, el 1er evento via chat de El Dia del Usuario Ubuntu.  El canal de las charlas estaba moderado, es decir, nadie podia escribir en el canal, solo los exponentes, el canal de preguntas si estaba libre por lo que era ahi donde ademas de realizarse las preguntas por tema, las personas conversaban entre si intercambiando sus opiniones y experiencias. Claro esta, pasaba gente que preguntaban cosas de Ubuntu que no estaba relacionado a las charlas, por lo que se les pedia muy cordialmente que por favor asistieran al canal oficial ubuntu-es puesto que ubuntu-charlas-chat era un espacio dedicado unicamente para las charlas del dia, especificamente a preguntas de la tematica expuesta al momento.  Tambien hubo unos intentos de spam de una direccion CTCP que cuando algunos usuarios clickeaban, hacia que el navegador de esta persona se conectara al canal por medio de su ip haciendo ruido en el chat, lo cual lamentablemente luego de notificarselo, la persona era expulsada de la red por error, pero igual podia volver a entrar y ya estar al tanto de no clickear ningun link externo dentro del chat, obviamente esto del spam se repitio en varias ocasiones por descuido y falta de saberlo de otros usuarios que en el transcurso del dia ingresaban y salian del canal.

El log de las charlas del Dia del Usuario Ubuntu puede verse en este enlace, mas informalmente desde los clasicos logs  de freenode, pueden verse en su version en html y en txt, desde luego, solo existe el log de la sala de las charlas, no hay log del canal de preguntas, ya que las preguntas igual eran copiadas en el chat de las charlas, ademas de que en el chat de preguntas obviamente habria mucha basura (conversaciones incluso separadas de la conversa del evento).

La Introduccion fue lo mas aburrido, es decir, recordemos que hablamos de un evento via chat, pero lo pautado era que la presentacion durara una hora, ordenes de arriba (como quien dice), hasta Pablo y Diego indicaban que efectivamente era la parte mas aburrida del dia pero obviamente es necesario una Presentacion e Introduccion para dar inicio a las charlas.

Debo decir que los mejores exponentes del dia fueron Fabian Rodriguez (Como asegurar que su material funcione antes de comprarlo), material=hardware y Andres Mujica (Reporte de Bugs, participar en el BugSquad) a los cuales les doi un rotundo 10 por su contenido, a IngForigua (Programas Equivalentes en Ubuntu) le doi un 7 ya que hubieron muchos puntos donde solo se mencionaban varios programas como equivalentes para determinadas areas de trabajo, pensaba que habria mas participacion del publico sobre la preocupacion de si aun existe o no software de alguna rama de trabajo en Ubuntu y que tan madurado estos estarian, ya que hablar de esto es atacar de lleno la razon que hace o deshace a que usuarios de otros sistemas se pasen a Linux, pero es claro que no se podia tocar tan detalladamente cada equivalente, se necesitaria todo un dia para ello, pero era informacion que facil se podia leer en google por asi decirlo por lo que, por el contenido le doi el la puntuacion ya inicada.

A Jorge Dardon (Linea de Comandos Part1) le doi un 4 debido a que para una hora de exponencia, se la llevo en su mayoria en las instrucciones por consola mas sencillas y basicas posibles, pensaba que en algun momento subiria el grado de complejidad y que convinaria instrucciones por terminal, asi como indico Jorge, le quedo un poco corto el tiempo en comparacion con las intrucciones que dio, hablar de la terminal y sus alcances en Linux es un tema que facilmente puede llevarse mas de una hora sin problemas, el fallo de Jorge seria no haberse planificado una version mas resumida y pasando un poco a tips de mayor embergadura referente al manejo de la terminal del sistema, ya que es comprensible abarcar parte de la charla a usuarios newbie, pero en esto tambien hubieron presentes usuarios de nivel medio y avanzado, yo soy de nivel basico pero todo lo expuesto por Jorge no salio de explicaciones basicas asi que era obvio que su ponencia aburriese un poco a usuarios mas experimentados, pero no estuvo mal, solo que pudo haber sido mejor, ya sera para la proxima del dia del usuario ubuntu  : )

Leandro Gomez (Como participar en mi LocoTeam mas cercano) asi como se lee y de saberse, era un tema Importante para unos y algo irrelevante para otros, pero… quien no estaria interesado en participar en eventos de Linux apoyando y asistiendo a tu comunidad local en lo que puedas, ser y sentirte parte de una comunidad, estar serca de personas que aprecian lo que tu aprecias. Las comunidades con sus eventos es algo que los usuarios de otros sistemas envidian, ya que esto de Comunidad no existe en otras plataformas, siendo esto un paraiso para personas del area. En resumen, a Leandro y a n0rman quien aporto al final de la charla, les doi un 8 que podria subir sin problemas a un 9, otra cosa,  como comento m4v en el chat de preguntas o como lo recuerdo, “habran evaluado bien las cosas al momento de identificarlo como “LoCo” a un local comunity team?”, nada de que usar como de doble sentido para el habla Ingles, pero para el habla castellana resulta incluso un poco humoristico decir que cada pais tiene al menos un LoCo y como ayudar al LoCo de tu comunidad y demas semajanzas  : )

Roni Cardona (Linea de Comandos Part2), lamentablemente para Roni le doi un rotundo 3 en la puntuacion, no porque no haya estado al principio de su charla en el canal de preguntas, sino porque tardaba mucho en presentar su contenido, pareciendo como si estuviese tipeando de un libro cada parrafo de su ponencia, ademas de verse un error en el titulo de su ponencia en comparacion con la tematica que realmente dio. Yo tenia una pregunta que hice en la hora de Jorge Dardon, pero el spam al momento no dejo visualizarla para los presentadores y participantes que las colocaban en el canal de la charla, en vista de que Jorge no salia de temas basicos de consola, decidi dejarla para la 2da parte con Roni, pero resulto ser un contenido no muy apegado al titulo de la ponencia. Si se puede trabajar con paquetes desde la Terminal como muchas cosas, pero realmente el titulo debio de haberse referenciado a la gestion de paquetes desde la terminal, indicar solo “Lina de Comandos” es algo muy generalizado y es mejor indicar las palabras que son las que seran protagonistas muchas veces en la charla, esto es mas que entendible, no es necesario esforzarse mas por explicarlo. Tambien fue uno de los exponentes que se retiro rapido luego de su charla, aunque no tardo en volver al canal y quedarse como los demas, no se si sea que es su primera exponencia, pero si creo que definitivamente le falto mejorarlo.

Las dos ultimas charlas se movieron de lugar, debido a que para la siguiente charla quien seguia tuvo problemas con su conexion y se retraso, y claro, para evitar retrasos luego de esperarse unos minutos, paso el siguiente y de llegar esta persona (que asi fue) seria entonces el ultimo en exponer.

Sergio Meneses (Sistema de Archivos y Permisos), es decir, una charla sobre esto, la cual le doi un 8, no dio el tiempo pero no por culpa del ponente aunque supongo que en el transcurso de sus ponencias miden frecuentemente el tiempo para saber cuanto les queda y asi tratar de no dejar puntos por fuera. Realmente esta charla y la de como particupar en el LoCoTeam mas cercano puede tener uno o dos puntos mas, esto dependiendo del usuario, quien no conoce nada del sistema, todo le parece nuevo e interesante, para otros usuarios, que no necesitan tener anios sino algunos meses, ya conocen de alguna manera el manejo de algunas de las cosas de estas charlas, viendolas como necesarias pero no tan importantes, es posible que vea esto desde ese punto de vista. Lo que si podria opinarse favorable o desfavorablemente seria como se condujo todo, si el exponente abarco bien su tema, si fue entendible, si las preguntas fueron contestadas aclarando el punto, si fue cordial el expositor, si realmente se preparo o no para la charla, etc.

Es claro que no necesariamente el conferencista deba saberselas todas, entre los usuarios presentes como espectadores muchos conocen tan bien o mejor algunas cosas de la misma charla y ayudaron a responder varias de las dudas de otros, usuarios basicos, medios y avanzados todos juntos y revueltos en un mismo canal, como lo ha sido siempre, el hermano mayor ayudando al hermano menor  : )

Sabiendo que este seria hasta la fecha mi post mas largo, coloco los tips que me resultaron sumamente importantes que debe conocer todo un usuario de Ubuntu Linux (o linux en general).

No es toda la charla pero si en su mayoria, colocando solo lo que para mi punto de vista, fue lo mas importante de estas.

Charla de Fabian Rodriguez sobre: Como asegurar que su material(hardware) funcione en Ubuntu antes de comprarlo.

[18:09] <+MagicFab> En general Ubuntu y Linux se apoyan en documentacion y especificaciones abiertas.
[18:09] <+MagicFab> Si estas no existen o un fabricante no las quiere compartir, o si el fabricante las comparte pero con restricciones legales (ej: patentes)...
[18:09] <+MagicFab> ahi­ es cuando pueden surgir problemas.
[18:10] <+MagicFab> Tambien hay fabricantes que tecnicamente miran que mercados les convienen... y aunque no hubieran limitaciones tecnicas para compartir y hacer funcionar su material...
[18:10] <+MagicFab> no hay incentivo economico.
[18:10] <+MagicFab> Por ultimo, hay lobby para que en una relacion de negocios, cierto material especial tecnicamente funcione *bien* con un sistema operativo
[18:11] <+MagicFab> Quizas el ejemplo mas famoso sean los Ipod
[18:11] <+MagicFab> Pero muchas impresoras, webcam, scanner, camaras, etc. se ven afectados por esto.
[18:07] <+MagicFab> Empezando, mucha gente que llega a Ubuntu / Linux se pregunta por que cuando algo funciona en WIn/Mac, no funciona en Linux ?
[18:07] <+MagicFab> La verdad la mayori­a de ese hardware viene con su drivers y es disenado para Win/Mac.
[14:27] <+MagicFab> Primero, si ya tiene el material, no "dañe" su sistema intenado habilitarlo:
[14:27] <+MagicFab> - No compile ni instale scripts manualmente: busque "package atheros driver ubuntu" por ejemplo
[14:28] <+MagicFab> - Use una nueva partición o un disco duro distintio si no hay otra opción que instalar "en vivo"
[14:28] <+MagicFab> Segundo, sea eficiente en su búsqueda en línea:
[14:29] <+MagicFab> - Use los sitios enumerados aquí, o pregunte "dónde puedo verificar compatibilidad de scanners en Linux" ?
[18:13] <+MagicFab> Resumiendo este punto, casi siempre hay una relación *comercial*, y razones *legales* y/o *técnicas* que, combinadas, hacen que un determinado material funcione en Win/Mac. Si ese contexto no existe en LInux/Ubuntu, ---> problemas.
[18:13] <+MagicFab> Nvidia es un buen ejemplo. Se PUEDE hacer funcionar. Pero si falla... alguien sabe cómo reportar un bug a nvidia ?
[18:14] <+MagicFab> Es en un formulario cuyo resultado... es privado: http://www.nvidia.com/object/driverqualityassurance.html
[18:15] <+MagicFab> Material con driver privativo a veces es incluso peor pues no es posible actualizarlo y no se puede arreglar los problemas por la comunidad.
[18:17] <IngForigua> andr3s_: <PREGUNTA> y que tal es la relacion con el hardware para servidores? por ejemplo, multiprocesadores, SAN, iSCSI??
[18:18] <+MagicFab>  andr3s_: es mucho mejor, ya que detrás de muchos servidores hay pérdidas medibles en $ cuando el material no funciona... por tanto muy fuerte incentivo de resolver esos prioblemas.
[18:18] <+MagicFab>  Esas perdidas pueden ser "servidores no vendidos"- es una razon por la cual Dell por ejemplo certifica su líneas... y HP igual.. y así van compitiendo...
[18:19] <+MagicFab>  Y ese proceso de certificación comercial.. NO es fácil.
[18:19] <+MagicFab>  Miren para referencia, este es el proceso para Windows:
[18:19] <+MagicFab>  http://www.microsoft.com/whdc/winlogo/logofaq.mspx
[18:20] <+MagicFab>  Imagínense un fabricante que pasa por eso.. y deba pasar por algo similar para Mac y / o Linux...
[18:20] <+MagicFab> sencillmente hay empresas que no tienen dinero o recursos para hacerlo
[18:21] <+MagicFab> Lo primero, como indicaba antes, es saber qué fabricantes están detrás de una componente, sea un sistema completo o una compoonente individual.
[18:21] <+MagicFab> Por ejemplo muchas webcams tienen la misma marca y modelo y adentro traen chips diferentes!!!
[18:21] <+MagicFab> Por reputación, con el tiempo, he identificado tendencias simples.
[18:22] <+MagicFab> Logitech, por ejemplo no soporta "ni soportará" (así contesta a quienes preguntan) nunca Linux.
[18:22] <+MagicFab> Entonces hay que ser lógico.. comprar una webcam de logtech requiere buscar primero si alguien logró hacerle algún truco mágico :)
[18:23] <+MagicFab> Por ejemplo, ud.s creen que esta cámara funcione en Linux:
[18:23] <+MagicFab> http://www.ncix.com/products/?sku=45803&vpn=H5D-00002&manufacture=Microsoft
[18:24] <+MagicFab> Les dejo adivinar si la funcionalidad HD, el autofocus y el noise cancelling funcionarán ?
[18:24] <+MagicFab> Esuna cámara NO diseÑada para Linux entonces será un asunto de ensayo/error
[18:24] <+MagicFab> Por reputación, algunos fabricantes deben evitarse:
[18:24] <+MagicFab> Broadcomm, VIA, ATI/AMD...
[18:25] <+MagicFab> Nvidia tiene buen soporte... pero no es libre y yo diría es "el menos peor" de aquellos
[18:25] <+MagicFab> Otros se destacan por su buen soporte:
[18:25] <+MagicFab> Hewlett Packard (impresoras), INtel (audio, wifi), Atheros (wifi)
[18:26] <+MagicFab> Y algunas categorías de material rara vez tienen problmea (por ejemplo pendrive USB o lectored de CD, o controladores de disco IDE)
[18:32] <+MagicFab> La presión comercial es el único incentivo apra que un fabricante soporte su material en linux. Se logra:
[18:32] <+MagicFab> NO comprando material que no tenga spec/doc libre y sin restr legales
[18:33] Affar[ES]: ?Es cierto que no es aconsejable comprar Hardware demasiado nuevo debido a que puede tardarse en haber soporte para Linux (Ubuntu en este caso)?
[18:34] <+MagicFab> Affar[ES], totalmente falso. Impresoras HP salen al mercado con soporte ya incluido para Linux por ejemplo. Depende de qué material sea, las mismas reglas se aplican.
[18:35] <+MagicFab> En algunas categorías de material, por ejemplo impresoras, también hay fuertes comunidades dedicadas a documentar el soporte (oficial o no) existente
[18:36] <+MagicFab> Por ejemplo es sabiudo que una impresora HP rara vez no funcionará,,, y que es necesario el paquete hplip-gui para instalarla adecuadamente y tener cosas como niveles de tinta, impresión y scan en red, etc. sin hacer NINGUNA configuración.
[18:36] <+MagicFab> hplip-gui es part de Ubuntu desde al menos 8.04
[18:36] <+MagicFab> Para otras impresoras, la comunidad se concentra en http://www.linuxprinting.org
[18:36] <+MagicFab> En el caso de dispositivos USB, hay un recurso menos pulido :) Pero igual de útil:
[18:37] <+MagicFab> http://www.qbik.ch/usb/devices/
[18:37] <+MagicFab> Esos son sólo dos ejemplos.
[18:37] <+MagicFab> En este sitio hay *DECENAS* de sitios dedicados a "listas de compatibilidad linux": http://www.linux-drivers.org/
[18:37] <+MagicFab> Cómo encontrar la guja en un pajar ?
[18:38] <+MagicFab> El objetivo de hoy no es mostrarles cómo buscar...
[18:38] <+MagicFab> pero algo muy obvio que mucho no ensayan es en google escribir simplemente el nombre del dispositivo y "ubuntu"
[18:39] <+MagicFab> en el caso de dispositivos usb, la regla es usar su identificador USB (que se encuentra usando el comando lsusb)
[18:41] <+MagicFab> Si sus 3 vecinos compraros laptops Acer y funcionan super bien... ud. comprará un laptop Toshiba ?
[18:41] <+MagicFab> Es una regla que puede parecer obvia... pero buscar ejemplo *recientes* que correpsondan a su versión de Ubuntu de gente aque diga "funciona" o "no funciona" hace parte de la tarea.
[18:43] <+MagicFab> Es importante compartir públicamente en foros, microblogging, blog, donde sea, cuando a uno le funciona algo - o cuando no le funciona también!
[18:50] <+MagicFab> Igual que Microsoft, Apple y otros, Ubuntu tienen un programa de certificaciuón de material
[18:50] <+MagicFab> PERO NO DE COMPONENTES
[18:51] <+MagicFab> Al menos no por ahora
[18:51] <+MagicFab> Y perdón, debí decir "Canonical"
[18:51] <+MagicFab> La lista de sistemas certificados está aquí: http://webapps.ubuntu.com/certification/
[18:52] <+MagicFab> Estas son empresas que han pagado Canonical para verificar si tal o tal sistema cumple con requisitos técnicos.
[18:52] <+MagicFab> Respecto a componentes, muchas veces algo que funcione en "linux" funcionará también en Ubuntu. El ejemplo que daba antes de las impresoras y su sitio de comunidad aplica aquí.
[18:53] <+MagicFab> Asimismo es uimportante conocer bien la documentación oficial al respecto
[18:53] <+MagicFab> Por ejemplo esta página ayuda mucho:
[18:53] <+MagicFab> https://help.ubuntu.com/9.10/switching/preparing-hardware.html
[14:29] <+MagicFab> - Busque "ubuntu" y el modelo de su material. Hay tantos usuarios de UBuntu que es muy probable alguien haya reportado falla o buen funcionamiento antes
[14:30] <+MagicFab> - CUando encuentre algo, verifique la fecha. Un blog de hace 3 años seguramente dejará su sistema inservible!!!
[14:30] <+MagicFab> Tercero, soport comercial vs. comunitario
[14:30] <+MagicFab> - Si su problema le está afectando su negocio o es importante, quizás valga la pena pagar soporte comercial. Canonical ofrece planes de
soporte *ilimitado* a partir de ~U$50
[14:31] <+MagicFab> - Pregunte en su localtema si hgay consultores o profesionales locales idspuestos a cobrar por el servicio
[14:31] <+MagicFab> Cuarto, documente y comparta!
[14:32] <+MagicFab> - Publique en blog, microblog o foros los resultados (buenos o malos) de lo que ud. quiere hacer - así es como otros lo encontrarán con
un motor de búsqueda!! No subestime esto.
[14:32] <+MagicFab> Quinto... el armal MORTAL FATAL!!!!
[14:33] <+MagicFab> - Use el Live CD para probar el material antes ANTES de comprarlo. EN muchas tiendas el personal aceptará esto si se ele explica de
manera cortés :) Ellos prefieren una pruebbita que una devoluvión y reembolso no ?
[14:33] <+MagicFab> Bueno, así concluyo la charla. Si hay algo pendiente les pido que me buisquen en #ubuntu-co, asimismo mi información de contacto está
aquí:
[14:33] <+MagicFab> https://wiki.ubuntu.com/UserDays/01232010/ChoosingHardwareThatWorks#preview
[14:33] <+MagicFab> Por su atención y paciencia gracias!!!

Algunos links que Fabian indico que atrajeron mi atencion fueron como por ejemplo para el caso de impresoras OpenPrinting, un agregado de eso por mi parte para el caso de Impresoras las mejores con una mayor taza de garantia de que funcionen son las HP, les seguirian luego las Epson, y luego el resto, Lexmark, Canon, por ejemplo de este ultimo Fabian tambien indica una seccion de Canon que no es exactamente un amplio soporte pero al parecer es lo mas cercano a ello, recursos para dispositivos de conexion USB que puede ser de utilidad, la lista de hardware validado para Ubuntu y sin dejar por fuera esta otra de hardware compatible, para el caso de dispositivos movil, laptops, pda, notebook, telefonos, etc TuxMobil, el log de charla de Fabian en el Ubuntu User Day se encuentra aqui. En resumen recomendaciones que siempre se deben de tener presente, investigar en internet o personas conocidas que hardware funciona perfectamente en Linux y en particular en la distribucion que uses, revisar si el hardware en tienda ya posee drivers para Linux o en todo caso llevar un LiveCD y explicarle al vendedor para permitir usarlo en el equipo y ver si existe o no algun problema de deteccion del hardware, que en algunos casos Linux lo puede reconocer pero no necesariamente lo identifica como ese “exacto” hardware que es, esto sucede cuando el hardware posee un chip del cual si existe driver pero no siempre y no necesariamente esta apegado esto a la marca del producto o su modelo, que igual cuando se busca informacion debe indicarse Marca y Modelo para dar con mayor precision en algun driver que funciona para dicho hardware. Investigar primero, no comprar y luego ver si sirve.

Charla de Andres Mujica sobre: Reporte de Bugs, Participar en el BugSquad

[22:13] <andresmujica> lo primero que debemos hacer al tener un problema es identificar si este es por configuracion o es un problema que requiera a un desarrollador
[22:13] <andresmujica> pero bueno como vamos a saber si el problema requiere ayuda "avanzada" ? es decir a un desarrollador, a un "guru" ??
[22:14] <andresmujica> existen varios criterios. Tu problema seguramente requiere un desarrollador cuando:
[22:14] <andresmujica> 1.- el programa se bloquea cuando realizo alguna actividad especifica, p.e. suspender
[22:15] <andresmujica> 2.- fallos despues de realizar una actualizacion
[22:15] <andresmujica> 3.- un dispositivo de hardware que antes funcionaba, no funciona ahora .. o peor.. nunca ha funcionado
[22:15] <andresmujica> 4.- cuando toda la gente a quien le pides ayuda te dice, hmm eso como que esta complicado.... :/
[22:16] <andresmujica> ahora, necesitas un master en informática o un desarrollador cuando:
[22:16] <andresmujica> 1. configuraste el firefox (o x programa) y ya no funciona
[22:17] <andresmujica> 2.- preguntaste en la lista de correos de tu locoteam y todo el mundo te dice como arreglar el problema
[22:17] <andresmujica> 3.- preguntaste en los foros  y varios amigos te ayudan con el problema
[22:18] <andresmujica> 4.- buscaste en google y encontraste 100 paginas describiendo 150 soluciones al problema
[22:19] <andresmujica> en estos ultimos casos, es probable que sea una desconfiguracion
[22:19] <andresmujica> o algo similar,
[22:19] <andresmujica> y en los primeros es cuando mejor dicho...
[22:19] <andresmujica> necesitas volver a la U o cambiar de carrera para resolverlos
[22:19] <andresmujica> :/
[22:20] <andresmujica> una de las grandes, grandes ventajas del software libre es la posibilidad innata que tiene de ser MOLDEADO A NUESTRO ANTOJO.
[22:24] <andresmujica> si tenemos claro cuando nuestro problema es o no un bug, podemos dar el paso de reportar el mismo.
[22:25] <andresmujica> LAUNCHPAD
[22:25] <andresmujica> el reporte de bugs en Ubuntu hace uso de LAUNCHPAD, siendo esta una increible herramienta desarrollada por Canonical
[22:25] <andresmujica> en mi concepto Launchpad es el aporte mas importante hecho por Canonical a la comunidad del software libre
[22:26] <andresmujica> incluso por encima de Ubuntu...
[22:26] <andresmujica> en los sistems de desarrollo de software existe lo que se conoce como BTS
[22:26] <andresmujica> un sistema en el que los desarrolladores manejan y controlan los bugs reportados por los usuarios.
[22:27] <andresmujica> Normalmente, estos BTS son muy intimidantes y tienen una finalidad muy especifica, el reporte de bugs
[22:27] <andresmujica> En cambio LAUNCHPAD es una plataforma que esta DISEÑADA para que el USUARIO se acerque a los DESARROLLADORES, de una manera amigable
[22:27] <andresmujica> permite CORRELACIONAR preguntas de soporte (Answers,p.e.) con reportes de bugs
[22:27] <andresmujica> enlazar codigo fuente con bugs especificos solucionando el problema a bajo nivel
[22:28] <andresmujica> Y algo que es sumamente valioso, permite crear SINERGIAS con los BTS tradicionales existentes, de tal modo que por medio de Launchpad un usuario , pueda interactuar con el CREADOR mismo del programa que esta usando.
[22:28] <andresmujica> Claro, para el caso particular de nuestra comunidad de habla hispana, tenemos una barrera adicional, a la  tecnica. El Ingles.
[22:29] <andresmujica> sin embargo, ciertos componentes (ANSWERS) serán traducidos eventualmente, y otros lastimosamente no lo serian...
[22:29] <andresmujica> primordialmente porque el desarrollo de mas del 90% del software que usamos en ubuntu se hace en ingles..
[22:30] <andresmujica> sin embargo, las politicas el bugsquad permiten reportar bugs en otros idiomas, SIEMPRE Y CUANDO este sea traducido por algun miembro del equipo de traducciones.
[22:31] <andresmujica> entonces un primer paso que todos deben dar es el de crear su cuenta en launchpad, esto lo pueden hacer mas tarde accediendo a https://launchpad.net/+login
[22:31] <andresmujica> bueno, listo, pero como reporto entonces un bug ??
[22:32] <andresmujica> este es un buen documento que da pautas para reportarlos http://www.chiark.greenend.org.uk/~sgtatham/bugs-es.html
[22:32] <andresmujica> les voy a dar una serie de recomendaciones para que sus bugs sean resueltos
[22:32] <andresmujica> o en su defecto rapidamente atendidos ;)
[22:32] <andresmujica> lo mas importante es que tu mismo puedas repetir el bug, y que puedas DESCRIBIR el procedimiento para repetir el bug.
[22:33] <andresmujica> La situacion es la siguiente, el desarrollador del programa necesita ver el error que se te esta presentando para poder resolverlo, si el no es capaz de experimentar el error en su sistema no podria arreglarlo.
[22:33] <andresmujica> Entonces el primer truco para asegurarnos que nuestro error seria resuelto, es garantizar que el error lo pueda repetir otra persona. :)
[22:33] <andresmujica> como se hace?  con un paso a paso, p.e.  1. Abra Rhythmbox.  2. De clic en Radio 3. de doble clic en una emisora 4. cuando la emisora este sonando, suspenda la maquina 5. Espere unos minutos 6. despierte la maquina, 7. espere un rato y el rhytmbox aparecera muerto o de doble clic sobre la emisora y se bloqueara. <- intentenlo ahora mas tarde y me cuentan
[22:34] <andresmujica> Este proceso lo puede seguir cualquiera y podria o bien repetir el bug o determinar si el bug es algo que se le presenta especificamente a mi equipo por alguna configuracion especifica en hardware o software.
[22:35] <andresmujica> Para descartar configuracion de software podemos descargar el livecd con la version que estamos usando de Ubuntu desde http://cdimages.ubuntu.com/releases/9.10/release/  y probar el mismo procedimiento con dicho livecd.
[22:35] <andresmujica> Otra buena practica es descargar la ultima version en desarrollo y hacer la misma prueba alla, en este caso seria http://cdimages.ubuntu.com/releases/10.04/alpha-2/
[22:35] <andresmujica> Si se repite podemos confirmar que no es una configuracion de software.
[22:36] <andresmujica> si tenemos la suerte de que el bug se presente en la ultima version en desarrollo, pues muchas mas probabilidades de solucion tendremos, el grueso de desarrolladores
[22:36] <andresmujica> esta trabajando en esta version
[22:37] <andresmujica> y ellos estan pendientes de los bugs que se presenten en este periodo
[22:37] <andresmujica> porque quieren solucionarlos!!!
[22:37] <andresmujica> vamos entonces en
[22:37] <andresmujica> 1.- repetir el bug y describir el proceso para que otro lo repita
[22:38] <andresmujica> 2.- probar con el livecd de la version actual y la de desarrollo para descartar problemas de configuracion y validar si puede se resuelto durante el ciclo de desarrollo vigente
[22:38] <andresmujica> Con esos dos puntos bastante terreno tenemos ganado.  (sin siquiera haber entrado a Launchpad aun :)
[22:38] <andresmujica> otro punto a tener en cuenta es
[22:39] <andresmujica> ser lo mas concretos y especificos posible
[22:39] <andresmujica> Es increible pero una gran cantidad de reportes de bugs son simplemente ignorados porque quien lo reporto no explico claramente el problema, o uso un lenguaje no apropiado o agresivo al reportar el bug.
[22:39] <andresmujica> bueno, vamos con calma.  aun no llegamos a reportar nuestro bug.  Por una razon simple e importante.  Si te ha ocurrido a ti­, es probable que le haya ocurrido a otro.
[22:39] <andresmujica> Por eso es que en mi concepto el truco mas importante es el de buscar un reporte previo de mi error.
[22:40] <andresmujica> Si consultan los logs de la charla de FindingHelp (https://wiki.ubuntu.com/UserDays/01232010/FindingHelp)  encontraran excelentes tips para buscar en google su error
[22:40] <andresmujica> los resumo en:  1. si tienes un mensaje del error que te sale (preferible en ingles) copialo, ponle comillas y buscalo por google.  2.  busca directamente en launchpad (pero por google)  es decir usando site:launchpad.net
22:41] <andresmujica> Si quieres ir mas alla busca en los foros de Ubuntu a alguien con un problema similar y valida si lo reporto previamente.  Otra muy buena opcion, es acceder a http://webchat.freenode.net/?channels=ubuntu-bugs  y preguntar si alguien reconoce el bug que se te presenta y si ya esta reportado.
[22:42] <andresmujica> este trabajo previo lo que lograria es que su bug ya este bastante listo para que un desarrollador lo pueda resolver
[22:42] <andresmujica> en este momento es cuando ya entramos a launchpad
[22:42] <andresmujica> aqui los remitire a este tutorial grafico (en espaniol e ingles) https://help.ubuntu.com/community/ReportingBugs/ o https://help.ubuntu.com/community/ReportingBugs_es
[22:42] <andresmujica> al reportar el bug tenemos en cuenta lo mencionado previamente
[22:43] <andresmujica> y nos apalancamos en las herramientas disponibles en Ubuntu
[22:43] <andresmujica> - usar la opcion en el menu de ayuda - Reporte un problema
[22:43] <andresmujica> - usar ubuntu-bug nombre-paquete
[22:43] <andresmujica> al ejecutar cualquiera de estos procedimientos se recopilara la informacion necesaria de tu sistema y se abrira una pagina en launchpad.
[22:43] <andresmujica> en esta pagina se mostraria un listado de posibles duplicados de ese bug.
[22:44] <andresmujica> Es muy, muy importante darse tiempo para mirar los reportes y encontrar si el bug ya esta reportado.
[22:45] <andresmujica> una buena practica es que en caso de haber encontrado un reporte previo del mismo error, nos suscribamos a este reporte,
[22:45] <andresmujica> creemos el reporte de nuestro bug
[22:45] <andresmujica> y lo marquemos como duplicado del ya existente
[22:45] <andresmujica> puede ocurrir que mas adelante se evidencie que tu bug no era duplicado, asi se podria separar y manejar por aparte.
[22:46] <andresmujica> otra recomendacion es que el reporte lo hagas con la ultima version en desarrollo (con el livecd que mencione antes)
[22:46] <andresmujica> y en el caso que ya tengan reportes de bugs hechos
[22:46] <andresmujica> pueden adicionar informacion relevante con el comando apport-collect
[22:47] <andresmujica> los casos mas dificiles que tenemos en Ubuntu estan relacionados con HW
[22:47] <andresmujica> ya varios de ustedes han mencionado que las webcam es una utopia en ubuntu
[22:47] <andresmujica> el asunto es que todo iba muy bien hasta mediados del anio pasado
[22:48] <andresmujica> cuando los gurus del kernel dijeron que todo lo relacionado con procesamiento de senales (es decir la senal de video) no se puede manejar a nivel de kernel
[22:48] <andresmujica> los esfuerzos para desarrollo de drivers de las QC, y muchas otras sufrieron un reves
[22:49] <andresmujica> porque les toco separar su funcionalidad en dos
[22:49] <andresmujica> una para el kernel y otra a nivel de usuario...
[22:49] <andresmujica> entonces lo mejor que puede ocurrir cuando uno tiene un bug relacionado con HW
[22:49] <andresmujica> es identificar de manera unica el HW
[22:49] <andresmujica> p.e. con dmidecode
[22:49] <andresmujica> on lshw
[22:49] <andresmujica> con lspci
[22:50] <andresmujica> que dan identificaciones de bajo nivel para el HW que se tiene
[22:50] <andresmujica> y permite encontrar bugs relacionados con el mismo hw.
[22:50] <andresmujica> la forma mas facil de reportar este tipo de bugs es coin
[22:50] <andresmujica> ubuntu-bug linux
[22:50] <andresmujica> que tomaria toda la info requerida de HW y armaria el reporte para subir a launchpad
[22:52] <andresmujica> ok, les decia entonces que si ya tienen un reporte pueden complementarlo con apport-collect numero_de_bug
[22:52] <andresmujica> esto lo que hace es recopilar la info necesaria de acuerdo al bug y subirla a launchpad
[22:53] <andresmujica> ahora, un punto muy importante... la REALIDAD
[22:53] <andresmujica> no hay suficientes personas ni desarrolladores
[22:53] <andresmujica> para resolver todos los bugs que estan reportados en launchpad
[22:53] <andresmujica> en cada ciclo estamos hablando de mas de 3000 bugs reportados contra el kernel de linux
[22:54] <andresmujica> y si mal no estoy no alcanzamos a tener 10 desarrolladores de kernel en ubuntu....
[22:54] <andresmujica> peor aún, no tenemos suficientes personas que realicen TRIAGE para analizar los bugs y ayudar a su pronta solucion
[22:54] <andresmujica> el bugsquad los necesita!
[22:54] <andresmujica> es por esto
[22:55] <andresmujica> que muchas veces cuando ustedes reportan un bug parece que fuera totalmente olvidado e incluso inutil
[22:55] <andresmujica> aqui va el siguiente tip
[22:55] <andresmujica> en estos casos debemos monitorear permanentemente el bug
[22:56] <andresmujica> si sale una version alpha o un nuevo release probar de inmediato con un livecd
[22:56] <andresmujica> para validar si continua o ya se resolvio
[22:56] <andresmujica> es increible pero la actividad mas frecuente de un triager es preguntar si ya probaron con la ultima version
[22:56] <andresmujica> imaginense pagarle a 10 mechudos expertos en programacion para que le pregunten a miles de personas si ya probo con el ultimo cd ?
[22:56] <andresmujica> en vez de que esten resolviendo el bug!!!
[22:57] <andresmujica> tambien es buena practica pasar por #ubuntu-bugs y preguntar si alquien ha tenido la oportunidad de revisar tu bug
[22:57] <andresmujica> normalmente en ese canal hay unas 100 - 120 personas dispuestas a ayudar
[22:58] <andresmujica> <Pregunta de un usuario> Puede un programa de terceros causar un bug del cual no responda Canonical por no ser propio del sistema, sino algo ocasionado por externos?
[22:58] <andresmujica> sip, muchos programas causan bugs en el sistema
[22:58] <andresmujica> un ejemplo es el adobe air
[22:58] <andresmujica> la primera versión no he validado si ya se resolvio
[22:59] <andresmujica> que ejecutaba un script bastante dañino y dañaba menus y varios items en Ubuntu.. por mala programación
[22:59] <andresmujica> en esos casos la  politica oficial es que no podemos hacer nada
[22:59] <andresmujica> pero poco a poco
[22:59] <andresmujica> se han ido estableciendo puentes con adobe, p.e.
[22:59] <andresmujica> para interactuar a nivel de bug trackers
[22:59] <andresmujica> y poder resolver los problemas.
[23:01] <andresmujica> el bugsquad esta compuesto por personas que quieren colaborar en el manejo de bugs en Ubuntu, yo soy uno de ellos, en el canal #ubuntu-bugs encontrarian muchos mas
[23:01] <andresmujica> la funcion de los miembros del bugsquad es  lee tu reporte y define que nivel de importancia tiene, si es o no un error, te hace las preguntas pertinentes para completar la informacion si es el caso y lo alista para entregarselo a un desarrollador quien con toda la informacion completa podria trabajar en el y resolverlo en la medida de lo posible,
[23:01] <andresmujica> en este link puedes encontrar informacion de como convertirse en triager
[23:01] <andresmujica> https://wiki.ubuntu.com/BugSquad/GettingInvolved
[23:02] <andresmujica> el programa de mentorship busca ayudar a aquellos que deseen unirse al team en sus labores como triager
[23:02] <andresmujica> en este link tenemos mas informacion
[23:02] <andresmujica> https://wiki.ubuntu.com/BugSquad/Mentors
[23:02] <andresmujica> y les recomiendo mucho la lectura de https://wiki.ubuntu.com/Bugs/HowToTriage donde encontraran informacion mas profunda y tecnica sobre el tema.
[23:02] <andresmujica> Entonces, no me resta mas que decirles que el BugSquad los necesita! contamos con ustedes! y que espero les haya sido de utilidad esta charla.
[23:04] <andresmujica> Si alguno de ustedes esta interesado en hacer parte del BugSquad, con  mucho gusto les colaboraria. no duden en contactarme
[23:04] <andresmujica> Les agradezco mucho su asistencia, la proxima semana en el Developer Week se realizara una charla mas avanzada sobre bug triaging, donde estan cordialmente invitados.

Igual como la charla de Fabian, la de Andres fue todo concentracion del publico, todo lo que indicaba de principio a fin era informacion que valia la pena de tomar nota, ya que realmente no hay tanta gente que sabe como documentar un bug y reportarlo, por lo que desde que vi el cronograma o agenda del dia, sabia que esta charla seria una de las que se tendria mucho interes.  Hablo sobre lo importante que es el Launchpad de la gente de Canonical siendo este para la comunidad uno de los mejores medios de reporte de bugs del software libre, reportes de los usuarios para los desarrolladores, link de registro, indico un interesante e importante articulo de Simon Tatham donde el usuario puede conocer como informar de fallos de forma efectiva, link de descarga de la version actual de Ubuntu o la version Alpha2 de Ubuntu 10.04 LTS. Sus recomendaciones que ya muchos practicamos, copiar entre ” ” (comillas doble) el escrito del aviso en google bien sea solo, o acompanandolo (fuera de las comillas) la palabra launchpad para que google nos busque en el Launchpad bugs reportados que generen ese mismo error y sus posibles soluciones en caso de ya estar solucionado. Al igual que Fabian, hace incapie en los blogs, foros, etc, el dia a dia de un usuario de cualquier sistema, ademas tambien ofrecio el link de freenode del canal ubuntu-bug que en mi caso como muchos seria por nuestra interfaz actual de uso de irc. Tambien nos indico como reportar un bug por la GUI de Ubuntu, incluso por terminal con tipear man ubuntu-bug veremos como mandar bugs desde consola, por ejemplo ubuntu-bug nombre-paquete, explico el que obviamente se debe ver si el bug que se desea reportar no esta ya reportado, en caso de estar reportado pero no con el comportamiento de nuestro caso, indicarlo para haber mas documentacion que genera el mismo error, lo bueno de esto es que es posible que el arreglo de bug arregle mas de una forma o camino que conllevo a este, tambien asi como lo sostiene Andres, la deteccion de bugs debe hacerse desde la ultima version release (lista y estable) del sistema o programa. Tambien si hacemos un man apport-collect, comando con el cual se puede anexar mas informacion sobre el fallo, por ejemplo, apport-collect numero_de_bug para subirlo a Launchpad.  El que el usuario ayude a reportar y si es posible, a colaborar en la solvencia de fallos, ayudaria mucho a los pocos desarrolladores (Andres sostiene que a lo mucho la cantidad de desarrolladores esta por debajo de 10 personas) y la cantidad de bugs reportados hacia el kernel es mucha, donde indica que los que no esten bien documentados (bien explicados y de adecuadamente en su vocabulario) pueden ser omitidos/ignorados. Precisamente por suministrar ayuda de fallos esta el BugSquad del cual Andres es colaborador, en el irc ubuntu-bug se indicaria el levantamiento de informacion, se le da un nivel de importancia y los colaboradores le pasan esta informacion al desarrollador de ese programa el cual  ya con toda la informacion que necesita lo atenderia y esto ayudaria a solventarlo mas rapidamente. Mentorship para las personas que deseen ayudar al equipo de BugSquad, tambien indico que es y que hace un Triage y como ser un Triager. Sin duda alguna aprendi mucho de su charla (muchos lo hicimos).

Aunque en lo particular seria mucho mejor este evento por medio de Streaming, esto se ha llevado como lo vivimos ayer por los irc de freenode el cual posee una larga lista de canales como lo muestra sus logs por anio, mes y dia y ya ahi todos los logs de todos los canales de ubuntu de freenode. Tratare de estar mas pendiente de futuros eventos que posiblemente no hayan llegado a todos los grupos de usuario Ubuntu de la comunidad.

Las demas charlas tambien fueron muy copadas (como dicen los argentinos) pero solo copio nota de las que atrajeron mas mi atencion, y sin duda alguna, esto es algo que definitivamente debe volverse a repetir, todo salio muy bien asi que no deberia haber problema, no solo en otro dia del usuaro ubuntu, sino de muchos otros eventos que por las barreras del idioma no alcanzan a todos los usuarios de habla hispana. Existen expertos (como bien muchos los leimos ayer) que pueden seguir aportando sus experiencias y otros que se espera que se animen y participen en eventos de este tipo para este lado del mundo. El total de usuarios que ingresaron al Dia del Usuario Ubuntu fue de 90 en ubuntu-charlas y 71 en ubuntu-charlas-chat, apoyandome en m4v, un aproximado de casi 100 usuarios indicado por tatica, una taza de ingreso mayor que el canal oficial de ubuntu-es.

No soy ningun experto en Linux (Ubuntu en mi caso), uso Linux desde menos de un anio y realmente me he dedicado a estudiar mas de otras cosas a usar en el sistema (sobre el sistema) pero no me he entregado a entraniar cada parte del mismo, ya que tengo otras prioridades que atender primero. Me gusto mucho estas charlas, el Dia del Usuario Ubuntu es sin duda alguna uno de los mejores eventos de las comunidades de Software Libre que han podido implementar ya que aunque los eventos en persona considero son mejores, involucran un mayor esfuerzo en muchas cosas, aprendi varias cosas el dia de ayer en estas charlas, como muchos otros, y si eventos como este se siguen dando, esto enriquecera en un nuevo y mas amplio conocimiento que llevara mas de la mano al hermano menor y al iniciado en este tan bonito sistema como lo es Ubuntu Linux.


About this entry