Las mejores noticias

Un extracto de lo que publica Linux News Here en Google+ hoy.

“De acuerdo con Zacchiroli, las razones para conseguir que Debian sea apoyado por la FSF son varias: desde la prevención de duplicación de esfuerzos en muchas distribuciones derivadas de Debian hasta los problemas en las relaciones públicas que el proyecto está experimentando porque la distribución original no está incluida en la lista de la FSF (…) Para completar sus planes, Zacchiroli dice que está buscando personas voluntarias para que clasifiquen los problemas relacionados con esta situación. Su meta es lograr que Debian sea incluida en la lista de la FSF o preparar documentación que establezca claramente por qué la distribución no está incluida. En este último caso, espera que Debian al menos se deshaga de la confusión que experimentan potenciales personas usuarias cuando descubren que el proyecto – a la vez que claramente se adhiere a los ideales del software libre- no está apoyado oficialmente por la FSF”

 

Retos para el software libre en latinoamérica

Vladimir di Fiore de SOLAR Argentina y Carolina Flores de Software Libre Centroamérica estamos promoviendo una cyber-tertulia llamada: “Retos para el software libre en la actualidad”.

¿De qué queremos hablar?

En principio, nos gustaría conversar sobre el crecimiento del software libre en nuestros países, si somos consumidores o gestores, si la libertad de software se ha visto afectada por el auge del software libre a nivel mundial, cuáles proyectos son estratégicos para la región, entre otros.

Todos los temas serán bienvenidos y esperamos que llegue gente de todos los países de América Latina. Ayúdennos a difundir.


Canal IRC: #sl-centroamerica en freenode
Jueves 8 de marzo
18:30 México y Centroamérica GMT-6
19:30 Panamá GMT-5
21:30 Argentina GMT-3

¿Qué son las CyberTertulias?

Hace unos meses, David Narváez escribió a la lista de Software Libre Centroamérica para proponer las CyberTertulias: reuniones informales en el canal de IRC para tratar “temas que atañen al Software Libre desde el punto de vista del hacktivismo, y están por lo tanto enfocadas al impacto social de este movimiento. En otras palabras, aquí no enseñamos cómo configurar Compiz :)”. Las reuniones están motivadas porque “la comunidad de Software Libre Centroamérica se encuentra dispersa en una amplia región geográfica con poca facilidad de movilización (comparada con otras regiones como Europa) y es, por lo tanto, difícil tener encuentros presenciales donde discutir temáticas que afectan al activismo en Software Libre. Estas reuniones buscan promover el intercambio de opiniones e ideas entre los miembros de SLCA que tienen mayor interés y conocimiento acerca de los aspectos sociales y técnicos del Software Libre, y a la vez permitir que más miembros puedan conocer acerca de estos temas y aportar sus puntos de vista. Son, por lo tanto, reuniones de carácter estratégico y didáctico al mismo tiempo”.

Ya se han realizado varias pero no he podido participar más que en “la sobremesa” sobre ACTA, por el horario de mis clases. Ahora, hemos planeado una tertulia para jueves y ahí estaremos 🙂

Dennis Ritchie: Uno de los grandes de la “Primavera Nerd”

Esta es la traducción que hice del post que Rob Pike colocó en su Google+. Rob Pike (guardando las proporciones con Ritchie) es también un importante gestor de lo que hoy disfrutamos en la computación y actualmente trabaja en Google.

Aún no me ha dado permiso de poner el post pero asumo que no habrá problema. Si me pide quitarlo pues… tristemente lo quitaré.

…………………………………………………

Rob Pike  –  Ayer a la(s) 17:49  –  Público

Fui sorprendido al ver cuántas personas respondieron a mi post en Google sobre la reciente muerte de Dennis Ritchie. Su influencia en la comunidad técnica fue vasta y es gratificante ver que es reconocida. Cuando Steve Jobs murió hubo un lamento muy amplio -y bien merecido fue- pero es válido hacer notar que el resurgimiento de Apple dependió en grande del trabajo de Dennis con C y Unix.

El lenguaje de programación C es muy viejo ahora, pero sigue activo y aún es muy utilizado. Los kernels [núcleos del sistema] de UNIX y LINUX (el de MacOS y pienso que incluso el de Windows) son todos programas en C. Los navegadores de Internet y los servidores más importantes están en C o C++ y casi todo el resto de los ecosistemas de la Internet están en C o en un lenguaje dervado (C++, Java), o en un lenguaje cuya implementación está en C o en un lenguaje derivado (Python, Ruby, etc.). C es también un lenguaje común de implementación para firmware de redes. Y así sucesivamente.

Y todo eso, sólo en cuanto a C.

Dennis también fue la mitad del equipo que creó Unix ( la otra mitad fue Ken Thompson), que de una forma u otra (yo incluyo a Linux) corre en todas las máquinas de los datacenters de Google y probablemente en la mayoría de las granjas de servidores. La mayor parte de los servidores corre sobre kernels Unix; la mayoría de los navegadores web que no son de Micrsosoft corren sobre kernels Unix de alguna manera, incluso muchos teléfonos.

Y hablando de teléfonos, el software que hace correr la red telefónica está escrita mayormente en C.

Pero esperen, hay más.

A finales de los años 70. Dennis se unió a Steve Johnson para migrar Unix a la Interdata. Fuera de contexto es difícil ver cuán radical era la idea de un sistema operativo que se pudiera migrar o mover; en ese tiempo los sistemas operativos se escribían mayoritariamente en lenguaje de ensamblador y estaban firmemente empotrados a marcas específicas de computadoras, tanto en lo técnico como lo mercadológico. Unix, por su inusual posición (aunque no era el único) de ser escrito en un lenguaje de alto nivel, podría correrse en una máquina que no fuera la PDP-11. Dennis y Steve dimensionaron la oportunidad y para inicios de los años 80, Unix había sido migrado por la comunidad de código abierto -la cual aún no se llamaba así- a esencialmente cualquier minicomputadora existente. Eso significó que si yo escribí mi programa en C, éste podia correr en casi cualquier minicomputadora. De repente, la pareja entre el hardware y el sistema operativo se había roto. Unix fue el gran ecualizador, la fuerza que empujó la Primavera Nerd que liberó el programar de las garras de los fabricantes de hardware.

El hardware ya no importaba más, desde que todos corrían Unix. Y como no tenía importancia, el hardware compitió por su dominancia contra otro hardware; el software se daba por sentado. Windows obviamente jugó un papel en el surgimiento de x86, pero la gente de Unix sólo aprovecharon eso. El hardware barato significó instalacones baratas de Unix; todos ganamos. Todo ese desarrollo en red que inició a mediados de los 80 sucedió con Unix, porque ese fue el ambiente en el que se hiceron las cosas que eran realmente importantes. Si Unix no se hubiera migrado a la Interdata, la Internet, si es que hubiera siquiera existido, hoy sería un lugar muy distinto.

Leí en un obituario de Steve Jobs que Tim Berners-Lee hizo el primer desarrollo de la WWW en una NeXT box, creada por la compañía que Job tenía en aquel tiempo. Bueno, ustedes saben cuál sistema operativo corría en las NeXT y cuál lenguaje.

Aún a su manera modesta, creo que Dennis estaba muy orgulloso de su legado. Y con toda razón: pocos logran siquiera una fracción de todo eso.

Hasta pronto, Dennis, y gracias por toda la magia.

Nota: La licencia CC con la que comparto este blog no cubre los posts traducidos. Para conocer la licencia que el autor prefiere deben dirigirse directamente a él.

La motivación es el alimento del Software Libre

Como parte del proyecto que coordino para la Universidad Nacional en alianza con el Programa de Naciones Unidas para el Desarrollo y el Ministerio de Economía, el jueves 28 de abril celebramos por fin el evento EXPOSOL: Soluciones en Software Libre y Open Source, donde más de 15 empresas pudieron mostrar su catálogo de productos y servicios basados en software de código abierto. Esto se complementó con conferencias y experiencias, como la charla de Paul Frields de RedHat que dejó a más de uno preguntándose qué tienen que ver las comunidades con la innovación. Espero que pronto entiendan la relación (las presentaciones de las charlas se pueden descargar de aquí).

Nos ha tomado más de un año organizar el evento. En un principio, porque el manejo de los fondos y la tramitología que el proyecto exige no nos permite obtener los resultados de forma tan ágil como quisiéramos. Pero también, el proceso con las empresas no estaba lo suficientemente maduro. Ha sido pues, una buena casualidad, que hayamos retrasado EXPOSOL hasta este momento.

La idea original ya había surgido en una conversación previa a mi rol como coordinadora del proyecto. En aquel momento varias personas de empresas proveedoras de servicios basados en Software Libre y yo, habíamos imaginado un evento donde se pudiera evidenciar que en el país hay suficientes empresas capaces de responder a las necesidades del mercado y que esas empresas trabajan con seriedad. Existe en el imaginario colectivo la idea de que el Software Libre es cosa de locos idealistas hippies y que si contrato una empresa que administre mis servidores “linux” el día que fallen -bah, eso casi nunca pasa pero es la costumbre- los empleados de la empresa estarán en el Caribe tomándose unas piñas coladas… es la idea de que detrás de una corbata está el conocimiento y que detrás de un bigote está la experiencia que me da confianza…

Y bueno. Resulta que hay empresas en Costa Rica que basan su oferta de servicios en Software Libre y no son 10 ni 15, son más de 35. Algunas de ellas, son empresas de renombre con más de 15 años de experiencia que hasta ahora se atreven a admitirlo porque en estos tiempos, los clientes empiezan a pedir Software Libre y tener experiencia en aplicaciones de Open Source es una ventaja competitiva, no algo que se deba esconder como hacían antes. Otras, son empresas de jóvenes emprendedores que se han atrevido a crear opciones a partir de lo que mejor saben hacer. Pocas, pero muy valiosas, son las que tienen relación directa con las comunidades de software libre y varias de ellas estarán integrando un capítulo de Software Libre dentro de la Cámara de Tecnologías de Información y Comunicación (CAMTIC), órgano que agrupa a la mayoría de empresas de TI ene l país y que por largo tiempo se ha mirado como lejana al Software Libre.

Habría mucho para decir. Algunas empresas siguen usando corbatas, por ejemplo. Los clientes siguen esperando corbatas, lamentablemente. Otras, usan camiseta y pelo largo y eso no ha restado a su credibilidad. ¿Qué importa el tema de las corbatas? Pues no sé. A mi forma de ver, el rechazo al Software Libre tiene que ver también con que es gente joven la que casi siempre está implementando sus soluciones y nuestra sociedad sigue relacionando la juventud con la informalidad y la falta de compromiso (¡menudo error!). También tiene que ver con que el mercado sigue casado con la idea de que necesita una empresa enorme que le dé respaldo (¡en buena hora que existe RedHat también!). Entonces, lo bueno está en la variedad pero aún queda mucho trabajo por hacer. Las empresas que están vendiendo servicios aprovechando las soluciones que el Software Libre ofrece, deben comprender que la motivación no es un recurso inagotable y que el desarrollo de Software Libre depende de ese componente. Si no se nutre la tierra donde crece, si no se contribuye en retribución (que no siempre es económica) y si no se trabaja fortaleciendo los proyectos de desarrollo y difusión, el Software Libre se concibe como materia prima gratis y eso no es sustentable. Esa es la tarea que sigue, porque por cada batalla que ganamos, surge un nuevo reto. Y en eso estamos.

Firefox 4: mi feedback

Técnicamente no puedo opinar demasiado sobre el Firefox 4 en su versión Beta. Puedo decir que es rapidísimo. De sus otras ventajas aún no he podido disfrutar.

Pero quiero opinar sobre la experiencia como usuaria en el siguiente escenario:

1. Cuando yo toco el botón derecho del mouse en los navegadores que uso (Firefox 3.6, Iceweasel, Epiphany) la opción que aparece de primero es abrir el enlace sustituyendo la página actual y en segundo lugar, abrir el enlace en otra pestaña. La opción de abrir en otra ventana aparece en tercer lugar. En Firefox 4, se ha eliminado la opción 1 y eso hace que continuamente abra una nueva ventana en lugar de una nueva pestaña.

2. Me dirijo entonces a hacer lo que se supone es mi contribución como usuaria: opinar sobre eso para que el equipo desarrollador valore si debe cambiar o no. ¿Cómo hacerlo? Ni idea.

3. Acudo al menú que dice “Help” y me encuentro con una opción que dice “Submit Feedback”. En mi experiencia, enviar retroalimentación es decir qué me parece algo y eso puede se tanto para agradecer o felicitar, como para reportar algo como lo del menú ligado al botón derecho ¿no?

4. El problema, es que cuando pulso para dar retroalimentación aparece una página con este mensaje:

y un espacio de una línea donde caben 140 caracteres. ¡140 caracteres para dar mi mensaje!. Probemos:

Menú botón derecho eliminaron opción 1 confunde usuario abre ventana nueva molesto

me quedan 58 caracteres… pero no es suficiente para que yo tenga una experiencia agradable y sienta que mi retroalimentación es bienvenida. ¿Debería serlo? Tal vez no. Puede que sea un caso de una usuaria equivocando la función de la opción de “send feedback”.

Pero me quedan muchas dudas: ¿por qué el feedback debería ser triste? ¿quién dice que he tenido una mala experiencia con mi navegador? ¿por qué culpabilizar a la persona usuaria y hacer que se arrepienta de comunicarse con quienes pueden mejorar su navegador?

Me encantaría sugerir cosas a quienes se ocupen de eso en Mozilla. De verdad. Creo que es parte de lo que debemos mejorar en todos los proyectos de desarrollo. Necesitamos que las personas usuarias sientan la diferencia entre ser usadas por su software y usar un software que responde a sus necesidades.

¿Qué tal algo como esto?

(ninguna cara, ni feliz ni triste…)

El equipo que construye tu navegador estará agradecido de recibir tus comentarios. Queremos mejorar tu experiencia. Por favor envíanos tu reporte.

Acompañado de una encuesta muy básica que permita reportar algo de forma ágil, útil y esperanzadora. *** Por cierto, el mensaje en inglés es peor que en español porque dice “nuestro navegador” y no “tu navegador” como debería ser.

Ojalá este mensaje llegue a alguien que pueda tocar la puerta correcta en Mozilla. Tal vez, este feedback les sea útil.

PD: Aprovecho para recomendar Limesurvey para las encuestas. Es libre, excelente y mucho mejor que los formularios comunes. El formulario acerca de cuántos navegadores uso y otros temas, no ocultaba las preguntas que no me correspondía responder a partir de las respuestas ya dadas. Eso con Limesurvey sería mucho más elegante y agradable.

Lo bugs que sí y los bugs que no

Leí un correo de Ian Jackson en el que se refería específicamente al error de pensar que todas las personas pueden y deben reportar bugs. Me gustaría traducirlo completo pero ahora mismo no puedo. En resumen, más o menos planteaba -con más sinceridad de la que mucha gente agradece- que para el caso de Debian, si un desarrollador debe gastar dos de sus cuatro horas diarias de programación para responderle a personas usuarias que reportan bugs que en su mayoría, son errores de procedimiento… eso no es beneficioso para el proyecto debian. Para él, “mimar” a las personas usuarias de esa manera no contribuye en nada. Habla de varias falacias muy interesantes y si leen inglés, por favor revisen el correo antes de seguir leyendo aquí (que mi resumen es muy pobre, la verdad).

Aunque puede parecer chocante… la verdad sea dicha: tiene razón. Tiene razón cuando hablamos de proyectos de desarrollo de un sistema operativo o aplicaciones horizontales. Todos los desarrolladores saben cómo debe comportarse un sistema operativo. Es decir, en la mayoría de los casos, los reportes no le dirán nada nuevo y si no los hacen personas con suficientes conocimientos, no contribuirán en mucho a encontrar la solución. –> Hace un año me hubiera pegado por la mano por escribir una cosa así.

¿En dónde sí vale la pena reportar bugs?

No sé… imagino que en desarrollos como Gimp o aplicaciones para sectores u ocupaciones específicas. Ahí sí los desarrolladores no saben qué es lo que se espera del programa (supongo) y ¿se necesita de mucha guía de personas usuarias que sí saben qué es lo que el programa debe hacer o cómo, lo que imaginan, no puede ser implementado a partir de la herramienta?

¿Y entonces, cómo mejoramos el software?

También, es importante reportar el otro tipo de bugs… los bugs generados por la endogamia hacker: ¿qué cosas no son útiles a las personas usuarias? Habría que generar espacios distintos, algo como grupos focales que permitan recibir observaciones sobre cosas que no se reciben bien, errores comunes en una interfaz, campañas equivocadas o actitudes que nos alejan de los proyectos. Es decir, por mucho tiempo las personas que no programamos, hemos pensado que debemos convertirnos en lo que no somos, para poder reportar bugs y ayudar “de verdad”. Tal vez la pista esté en otro tipo de reportes que debemos hacer e incluso, en no reportar nada más, sino involucrarnos de lleno en organizar el cambio. Y ahí es donde topamos con pared: ¿en cuáles espacios podemos mejorar el software quienes no programamos? ¿tenemos que conformarnos con probar versiones nuevas de los programas? ¿tenemos que dedicar nuestra energía a aprender a reportar bugs apropiadamente en lugar de aprovechar las capacidades que ya tenemos?

Para nada de eso tengo respuesta. Yo sólo tengo dudas.

—————————-

Lamentablemente, este post tuve que rescatarlo. Desapareció, seguramente por torpeza mía y se perdieron entonces los comentarios de Gunnar Wolf 🙁

Debian cheat cube en español

Desde hace como un año le llevo ganas al Ubuntu Cheat Cube… quería hacer uno para Debian pero no me había tomado el tiempo. Me basé en el trabajo de Esteban Saracho ¡muchas gracias Esteban!

Ahora, ya está listo. Fue revisado por varios amigos pero la verdad, no incorporé todas las sugerencias que me dieron…

Fernando Estrada me envió una larga lista de correcciones o textos más precisos (no todo cabe en un cubito 😉 y de ese correo, tengo mucho para aprender. Me ayudó a eliminar algunas cosas que no eran comandos sino modificaciones a archivos de configuración y otros un poco peligrosos para manos inexpertas. Jeffrey Esquivel me envió otras correcciones y sugerencias. Tato (Rafael Rivas) colaboró también ayudándome a precisar los términos correctos. David Narváez me explicó cómo es la cosa con los permisos de lectura, escritura y ejecución ( finalmente entendí esta tablita). Muchas gracias a todos.

Ahora, lo que me toca es aprenderme los comandos y usarlos. La consola da la verdadera libertad al software libre… así que hay que conquistar esos territorios… para ir bajando aún más hasta llegar… ¿a las cavernas?

El Cubo de Comandos para Debian en español está en DebianArt.org

A desalambrar el software libre

defences

Imagen: Defences become fences N°2, de Enrique T

Para actualizar y ser justa: ya casi estamos terminando la traducción de la campaña http://windows7sins.org gracias a la ayuda de Gabriel Molina, un mexicano con el que he podido trabajar en conjunto superando la barrera del repositorio. Gabriel accedió a trabajar “a pie” y hemos revisado juntos todos los textos. Gracias Gabriel.

Constantemente digo en mis conferencias, que no hace falta ser experto para ser parte del desarrollo del software. Es decir, si no sabemos programar, los usuarios y usuarias podemos dejar de ser entes pasivos y convertirnos en gestores del software, colaborando en actividades de difusión y activismo, pero también traduciendo, documentando y reportando bugs. Son tareas menospreciadas, pero bien importantes.

Lo lamentable, es que eso es falso en la mayoría de los casos. Los proyectos de software libre siguen siendo espacios pensados por y para informáticos, quienes muchas veces piensan que es relativamente simple seguir su lógica. Les tengo una mala noticia: NO LO ES.

La primera y única vez que reporté un bug, lo hice a la gente de KDE por un problema con el Aamarok 2. Me respondieron más o menos, que si no sabía reportar un bug correctamente, mejor los dejara en paz. Nunca más reporté un bug en mi vida (al menos, directamente) y me quedé con el Amarok anterior. Yo quisiera, lo juro, poder reportar un bug de una manera tan hermosa como esta (vía magus) pero es imposible para mis capacidades. De manera que los bugs quedan descartados, bajo la premisa de “lo que no sirve, que no estorbe”. Ok. Puedo vivir con eso.

Si no puedo reportar bugs, puedo traducir… ¿cierto?

Puedo traducir con enorme felicidad y satisfacción si lo hago para Drupal. El sistema que usan es en línea y es sencillo, maravillosamente sencillo colaborar. En los translation sprint que hemos organizado en la RCSL llevamos dos módulos completos traducidos al español, en un trabajo que ha sido divertido y enriquecedor. Jamás frustrante.

En otro vecindario, la traducción de la campaña Windows7sins de la Free Software Foundation, no me ha traído más que tristezas. Desde hace dos meses tenemos los textos traducidos y revisados por tres personas, pero se decidió usar subversion, pedir llave pública, entrar por ssh y de ahí, ya no sé qué sigue. El caso es que los textos los tradujimos al mejor estilo cavernícola (con openoffice.org) y ahora tocaría meter línea por línea dentro de los archivos html que hay en savannah. Si hubiéramos tenido archivos .po ya todo estaría listo… tampoco estoy pidiendo milagros… pero con este sistema ha sido imposible para Eva y para mí -las que más nos hemos comprometido con el asunto- de manera que la campaña sigue sin estar traducida al español, y así seguirá hasta que alguien pueda hacerlo y se publique otra traducción no revisada. ¿Nuestro trabajo qué? Bien gracias, guárdemoslo de recuerdo.

Entonces… ¿cuál es la verdadera posibilidad que tenemos los y las usuarias de software libre, de convertirnos en gestores y gestoras del cambio? ¿cuál es nuestro papel, más allá de dar conferencias, vender camisetas o escribir en un blog? Dar conferencias no debe subestimarse, porque implica conocer bien los temas, estar preparada para responder muchas preguntas diversas y saber exponer claramente conceptos complejos… pero eso no basta. Sobre todo, cuando interactuamos con proyectos de desarrollo donde lo que vale es el código y no cuántas personas escucharon una charla e instalaron software libre después.

Yo, de todas maneras aprecio mis contribuciones y creo que son bien importantes, pero definitivamente creo que tenemos que hacer un mejor trabajo si queremos realmente trabajar por la libertad de los usuarios y usuarias. Ni todos somos poetas, ni todos somos programadores. Tendríamos que generar espacios y niveles de acción, que permitan que más personas se acerquen y hagan tareas que son capaces de hacer. Muchas podemos traducir, pero por favor, quítennos los alambres de púas.

Los trapos sucios de Ubuntu

Hace unos días, publiqué un post donde mencionaba el trapo sucio de Canonical respecto a sus criterios para decidir cuáles bases de datos usar para launchpad. En ese momento, me decepcionó enormemente leer en sus FAQ, que estaban dispuestos a usar Oracle y que por mucho tiempo se aseguraron de poder migrar los datos si Postgresql no les funcionaba… Yo dije ¡Plop! y decidí desinstalar el Ubuntu de mi computadora para evitar la vagabundería y entrarle al Debian de una vez por todas (gracias jmas).

Hoy, Marcelo envió a la lista de la RCSL, una noticia sobre Ubuntu, pero esta vez se trata de algo mucho más grave que la falta de compromiso de Canonical con el Software Libre. Se trata de esa falta de compromiso manifestándose en el irrespeto a los usuarios y sobre todo, a los colaboradores que desinteresadamente prueban las versiones en desarrollo. Se trata de Canonical sacrificando la libertad de los usuarios por buscar la “generación de ingresos”. Ya no me extraña y casi agradezco, que Ubuntu se denomine como un “linux” nada más y que no mencionen a GNU en ese engendro que están cocinando.

Se trata del asunto del  Bug #402767 Multisearch CSE breaks l18n+setfocus+images+cached+I’m feeling lucky functionality and “violates user trust” y la respuesta de Rick Spencer:

Gracias a todos por sus comentarios sobre este error. Gracias a todos por la prueba, el alfa y por contribuir en hacer kármica tan grande como se pueda. Agradezco el tono medido y respetuoso de la presentación de informes.

Tomo muy en serio estas preocupaciones. Permítanme resumir las cuestiones planteadas aquí, y proporcionar algunos datos y respuestas:

Hemos hecho algunos cambios en la versión Alpha 3 de Firefox relacionadas con cómo y dónde se procesan las consultas de búsqueda. Hemos introducido los cambios en este momento en un espíritu de experimentación con el fin de explorar y comprender la experiencia del usuario y los patrones de uso. Nos proponemos utilizar este código experimental, por lo menos hasta Alpha 4.

Experimentando con los colaboradores sin su consentimiento… ajá…

Tenga en cuenta que no necesariamente prevemos “Multisearch” como el código que queremos en una versión estable. Independientemente de las acciones que tomemos en respuesta a la información y retroalimentación dependerá de la información y la retroalimentación que obtenemos de este esfuerzo.

Esencialmente, hemos implementado dos cambios con el fin de recabar estos datos de uso:
1. Cuando los usuarios piden una nueva ficha, ven una página de búsqueda predeterminada.
2. Todas las búsquedas utilizan la página de resultados de búsqueda personalizados. Anteriormente esta página de resultados de búsqueda sólo se utilizaba cuando los usuarios hacían una búsqueda desde la página de inicio por defecto de Ubuntu.

Cambio # 1 fue un esfuerzo por explorar una mejor experiencia de usuario. En general, se ve extraño cuando los usuarios obtienen una página en blanco, sobre todo cuando se está utilizando ff [firefox] en una NETBOOK en modo de pantalla completa. La nueva pestaña, simplemente hace que la pantalla quede en blanco. Tomen en cuenta que Mozilla está estudiando “una nueva pestaña” y el comportamiento (http://labs.mozilla.com/2009/03/new-tab-page-proposed-design-principles-and-prototype/)

Si Mozilla y Google lo hacen no es lo que está en discusión. Lo que se discute es que alguien tenga que señalarlo como un Bug para que alguien dé un paso al frente y acepte que se incluyó esa funcionalidad, que en realidad es una aplicación espía.

Cambio # 2 es sólo un artefacto de recolección de datos de uso. Nosotros sólo podíamos ver qué partes de la interfaz de usuario de FF estaban utilizando las personas para hacer las búsquedas, si las enviábamos  a nuestra página personalizada. Este uso de datos es importante porque nos ayuda a canalizar los recursos de diseño y desarrollo de funciones útiles, y también es importante porque puede estar vinculada a la generación de ingresos.

La generación de ingresos que apoya el proyecto es una característica, no un “bug”. Sin embargo, somos conscientes de no tirar el bebé con el agua del baño [¿tirarlo todo por la borda?]. En otras palabras, debemos encontrar el equilibrio entre seguir ofreciendo al usuario una experiencia de alto nivel al tiempo que se aprovechan las oportunidades de ingresos.

… por medio del engaño y el spyware… al mejor estilo del software privativo… buagh

En términos de “qué tipo de datos de uso” estamos recogiendo, son simplemente los mismos datos que ya se han enviado a Google y Mozilla: el pedido de búsqueda, y el canal para la búsqueda. Se trata de los datos que ya están previstos y se recogen cada vez que un usuario realiza una búsqueda con un motor de búsqueda en cualquier lugar de la web, y estamos simplemente utilizando los instrumentos de Google para ver los resultados agregados.

Es que no es ni pena lo que debería darles… hasta Google dice abiertamente qué hace y cómo lo hace… y los usuarios para eso instalamos Customizegoogle y otros complementos… para resguardar nuestra privacidad… pero claro, ¿cómo vamos a desconfiar de nuestro “linux”?

Este error empezó con un tema específico, pero algunos reportes de errores han añadido asuntos. Creo que los siguientes asuntos planteados son preocupaciones que deben tratarse como errores:
1. La “barra Awesome” no hace búsquedas del tipo “feeling lucky”
2. La página de resultados de búsqueda personalizada no es estéticamente agradable
3. La página de búsqueda personalizada carece de funcionalidad (imágenes, vídeos, mapas, etc ..)
4. “Multisearch” no es un nombre descriptivo
5. La nueva interfaz de usuario en las páginas de nueva pestaña es visualmente desordenada, no es útil
6. Las conversiones de moneda no funcionan

Esa es mi parte “favorita” si la unimoa con la frase célebre: “La generación de ingresos que apoya el proyecto es una característica, no un “bug”. Porque sí, es importantísimo que se le cambie el nombre a “multisearch”… eso sí que es un error fundamental.

Vamos a tomar estas consideraciones muy en cuenta, mientras consideramos si se debe avanzar con los cambios en la experiencia por defecto de búsqueda.

¡PLOP!

Por eso, me traje el comentario que más me gustó de los que pusieron cuando se reportó el “bug” que no es “bug” para Canonical:

Roger dijo:

Esta es un flagrante abuso de confianza. Ustedes instalaron algo en mi computadora, que yo absolutamente no quería tener instalado. Aparte de la filosofía del FOSS, la cosa que hace que ame Linux es que no tengo que tener anuncios atragantándome la garganta cuando lo uso. O al menos no me sucedía.

Yo sugiero que remuevan esta porción de software de una vez. También sugiero que quien sea responsable en Canonical sea despedido, inmediatamente, y que se nos asegure que algo como esto no sucederá nunca en el futuro.

Y claro… ya hay quienes simplemente dicen: “desinstalen y listo“… pero no… los de Canonical, como dicen en México “¡Qué poca madre!”. No sé si Rick Spencer sigue siendo el representante de Canonical en GNOME Advisory Board pero deberían darle unas clases de lo que se denomina Libertad de Software.