Como pueden ver en mi captura de pantalla, en efecto, Lyx tiene la apariencia de de ser un procesador de texto corriente. Sin embargo, no lo es: utilizándolo, al escribir, uno sólo tiene que preocuparse por el contenido y la estructura lógica, no por el formato.

Captura de pantalla de Lyx

Basta entonces apretar una tecla, y el maravilloso sistema de procesamiento de textos Tex creado por Donald Knuth , y el paquete de macros LaTeX creado por Leslie Lamport, se ocuparán de hacer que nuestro documento adquiera un aspecto profesional, con una calidad de terminación imposible de igualar, para otros procesadores de texto. Aquí pueden ver el PDF generado por Lyx a partir del documento que se muestra en la anterior captura de pantalla:

Lyx es especialmente útil para quienes escribimos matemática, ya que es una excelente herramienta para generar documentos en LaTeX, pero sin necesidad de aprender LaTex. En efecto, practicamene todo lo que se escribe en matemática hoy por hoy, se escribe en TeX (y particularmente en LaTeX, que es uno de sus dialectos), ya que como dice un amigo mío “(La)TeX es simplemente la mejor herramienta que se ha inventado para representar fórmulas en la computadora” .

Sin embargo, LaTeX no es un procesador de textos convencional. Es más parecido a un lenguaje de programación, donde en vez de ver el documento tal como se verá en el papel, debemos darle a LaTeX una serie de instrucciones, como por ejemplo indicarle como se organiza lógicamente nuestro documento (por ej: decirle “esto es el título de una sección”, y LaTeX se ocupará de darle el formato adecuado).

Aunque LaTeX es realmente fácil de aprender y de utilizar, escribir directamente en LaTeX puede resultar intimidante para quienes están más acostumbrados a los procesadores de textos convencionales. Para los que deseen aprender LaTeX, recomiendo: The not so short introduction to LaTeX (or LaTex in 87 minutes).

Incluso para quienes sabemos escribir en LaTeX, Lyx puede ser útil para escribir un documento con fórmulas matemáticas, viendo estas fórmulas como se verán en el papel, al mismo tiempo.

La historia de Lyx también es realmente interesante: fue escrito inicialmente por Mathias Ettrich , y (según se cuenta en su página en Wikipedia) su búsqueda de una mejor interface gráfica para Lyx fue lo que en última instancia lo llevó a crear el proyecto KDE.

Para saber más sobre Lyx, pueden también visitar su página en Wikipedia.

El título que sirve de motivación a este artículo, está tomado del anuncio de la versión 1.5.0-beta 1 que acaba de ser publicada. Lyx es software libre y se distribuye bajo la GNU GPL.

Las patentes de software no le sirven a nadie

Leyendo una nota en el diario La Nación, me enteré que un jurado de San Diego (California) decidió multar a Microsoft en la impresionante cifra de 1500 millones de dólares por infringir la patente del formato de audio MP3, al incluir soporte para dicho formato en sus sistemas operativos Windows.

Aunque según la nota, la sentencia podría ser apelada por Microsoft, creo que el caso es útil para reflexionar; ya que ilustra muy bien los efectos nocivos que tiene el sistema de patentes de software (en los países que lo han adoptado, como EEUU), y muestra que ni siquiera las grandes companías como Microsoft, son inmunes a los enormes riesgos legales que este sistema crea.

Cabe mencionar que Microsoft es uno de los más ferviertes defesores de la supuesta necesidad del sistema de patentes de software para “formentar la industria del software” (¿será que ahora reflexionen, y cambien de idea?).

¿Podría la Internet ser lo que es hoy si por ejemplo el protocolo TCP/IP estuviera patentado? ¿Sería el formato MP3 tan popular si no estuviera soportado por los sistemas operativos Windows?

A diferencia del régimen legal de derecho de autor (que protege la expresión de una idea en el código de un determinado programa), las patentes de software tienen por objeto las ideas mismas. Vale decir que: derechos de autor y patentes de software son régimenes legales esencialmente diferentes.Si en un país se implementa un régimen legal de patentes de software, un programador puede ser demandado judicialmente por distribuir el código que él mismo escribió (sin copiarlo de nadie).

Quienes nos oponemos a las patentes de software, consideramos que el régimen legal de copyright (derecho de autor) ya es una protección legal suficiente para el desarrollo de la informática.

Las patentes de software crean monopolios artificiales e incompatibilidades forzadas entre los sistemas: sistemas que tecnicamente podrían ser compatibles, no pueden serlo por razones legales, lo que perjudica enormemente a los usuarios. Lejos de fomentar el desarrollo del software, efectivamente lo imposibilitan. Y hacen imposible la competencia para los “recién llegados” al mercado del software.

Posiblemente, los únicos claramente beneficiados a la larga por el sistema de patentes de software, sean los abogados especialistas en patentes.

Para terminar este artículo, les recomiendo leer la carta, que Donald Knuth (uno de los fundadores de la computación científica y el creador de TeX) dirigió a la oficina de patentes de EEUU, contra las patentes de software. Y también vistar esta página de la FFI, que contiene algunas citas sobre patentes de software.

Ayer comentábamos que Eric Raymond es una personalidad muy influyente en la comunidad, pero también un tipo bastante polémico. Fiel a su estilo provocativo y pragmático, en su último documento World Domination 201, escrito en colaboración con Rob Lanley, Raymond propone una estrategia para que GNU/Linux alcance la “dominación del mundo” en 2008.

¿Poqué en 2008? Según Raymond, de acuerdo a la ley de Moore, hacia esa fecha tendrá lugar una migración hacia los equipos de 64 bits que ya están empezando a aparecer, y con ello la oportunidad de que se establezca un nuevo sistema operativo dominante (que desplaze al MS- Windows) . En este escenario, quién ofrezca la mejor plataforma de 64 bits ganará la batalla por el escritorio. Hay tres jugadores listos para jugarla: Windows Vista (que no ha empezado nada bien, a juzgar por todas las críticas que ha recibido), Mac OS X y Linux 2.6.

Según Raymond, si la competencia se decidira hoy, la batalla la ganaría Mac OS X, que podría convertirse pronto en el nuevo sistema dominante. ¿Qué le falta a Linux para poder ganar? Según Raymond, lo más importante es soportar los formatos en que se distribuyen los contenidos que los consumidores desean acceder, tales como MP3 y DVD.

El problema no es tanto técnico como legal: Si bien es posible desarrollar codecs mediante ingeniería inversa para estos formatos (y de hecho, ésto ya se ha hecho para muchos de ellos), no es posible distribuirlos legalmente (al menos en EEUU, que es el mercado clave), pues se trata de formatos patentados (y a veces desarrollar un codec violaría también la DMCA)

Raymond propone una solución de compromiso, que consiste en que una empresa u organización distribuya un hipotético CD denominado The Codex, con todos los codex necesarios para soportar los formatos privativos (obviamente en formato binario, y pagando las licencias correspondientes).

Incluso Raymond sugiere que Linspire podría ser la companía interesada en desarrollar The Codex, que además se encuentra en una posición única para hacerlo, pues es la única distribución de Linux legalmente autorizada a distribuir los codecs para los formatos propietarios de Media Player (como resultado de un acuerdo al que llegó en un juicio sobre marcas contra Microsoft),y se unió al equipo de FreeSpire (la versión “comunitaria” de Linspire).

Según Raymond, esto sería una solución temporaria hasta que la mayor parte de los usuarios se haya pasado a Linux. Cuando esto ocurra, la comunidad de Linux podrá imponer sus propias reglas: los desarrolladores crearán sus aplicaciones para Linux, y los fabricantes querrán se su hardware sea soportado por Linux; e incluso la comunidad tendrá la fuerza suficiente para demandar con éxito, los cambios en la ley que se necesitan para terminar con las patentes de software y las DRMs.

Por supuesto que, la propuesta de Raymond generó reacciones encontradas en la comunidad. Algunas a favor, otras en contra. Cómo era de esperarse, Richard Stallman, fiel a sus convicciones, le contestó que él no podría estar de acuerdo con esa “solución de compromiso temporaría”, que por otra parte seguramente no sería temporaria (ya que él no conococe ninguna distribución de Linux que incluyera componentes privativos, que después los haya removido).

En esto creo que tiene razón Stallman: nada garantiza que esto será una solución temporaria, ya que el mismo Raymond, en su documento, señala que la hipotética empresa que distribuya The Codex, tendrá pocos incentivos para terminar con el problema de los formatos propietarios.

Le he oído decir a Stallman, en una conferencia en Chile, que el éxito que ha tenido el proyecto GNU (que el empezó sin dinero ni poder político que lo respaldara), demuestra que no hay nada más práctico que el idealismo, en el sentido de que siendo fiel a sus convicciones es como logró hacer algo que de otro modo no hubiera podido lograr.

The Art of Unix Programming

Siguiendo con la serie de artículos dedicados a lecturas recomendadas, hoy quiero recomendarles el libro The Art of Unix Programming (El arte de la programación en Unix) de Eric Raymond.

Fundador de la Open Source Inciative, desarrollador de fetchmail y autor del famoso documento “La catedral y el Bazar” (donde compara el modelo de desarrollo centralizado utilizado tradicionalmente en los proyectos de software, con el modelo abierto y descentralizado que utiliza el desarollo del núcleo de Linux), Raymond es sin duda una de las personalidad más influyentes del movimiento open source (aunque ciertamente muchas de sus posturas son bastante controversiales).

El libro que les recomiendo trata sobre sobre el diseño de Unix y su “cultura” (de la cuál GNU/Linux es un continuador). A pesar de lo que el título puede sugerir, no encontrarán en él el códigos de programas ni instrucciones para programar en ningún lenguaje en particular.

En cambio, trata de aspectos de diseño, ejemplificados con programas reales. Y compara la filosofía y el diseño del Unix, con los de otros sistemas operativos. Creo que es un libro de lectura indispensable para todos los programadores.

Reflexiones sobre la Wikipedia

La fundación Wikimedia ha anunciado que el pasado 8 de febrero, la Wikipedia en español ha alcanzado los 200.000 artículos. Sin duda, es una noticia alentadora el crecimiento que está teniendo la Wikipedia en nuestro idioma.

La Wikipedia es quizás el mejor ejemplo de que la filosofía de creación cooperativa de conocimiento que inspira al software libre, puede llevarse también a otros ámbitos, y que de pueden beneficiarse también de ella los usuarios no técnicos. Creo que deberíamos tener esto en cuenta cuando organizamos eventos de difusión del software libre: no debería faltar en ellos una charla de Wikipedia para público general.

Debo confesar que a pesar de ser un convencido de las ventajas del software libre, mi primera reacción al visitar la wikipedia fue “¡Esto no puede funcionar!”. Si cualquier persona, sin siquiera necesidad de registrarse, puede editar los artículos de la Wikipedia, ¿quién garantiza la calidad de los mismos?

Aún en los proyectos de software libre, siempre hay un núcleo de desarrolladores que controla el código, toma las decisiones de diseño, y decide por ejemplo que parches se aplican. Sólo algunas personas tienen permiso para escribir en el repositorio. Sino, probablemente ningún programa libre funcionaría (Uno siempre tiene la libertad de crear su propio fork, es decir su propia versión del proyecto).

En cambio, el modelo de la wikipedia es diferente. Cualquier persona puede en principio modificar inmediatamente un artículo, y el control de calidad se hace a posteriori, cuando algún otro wikipedista modifica el artículo.

Incluso al principio me sentí bastante frustrado, cuando escribí un artículo para la sección matemática de la Wikipedia (soy matemático profesional), y otra persona vino y lo modificó, reemplazándolo por una versión anterior, que considero de calidad inferior. ¿No debería tenerse en cuenta en los artículos, la opinión de los especialistas en el tema?

Sin embargo, aunque a veces se cuelan artículos irrelavantes, tendencios o con errores; en promedio, debo admitir que el modelo de la Wikipedia funciona: en general la Wikipedia suele ser una de las mejores fuentes de información que uno tiene a mano.

El modelo de la Wikipedia apuesta a maximizar la cantidad de contribuciones, y postula siguiendo la célebre frase atribuida a Linus Torvalds que “Dados suficientes ojos, todos los errores quedarán a la vista” (traducción aproximada del original en inglés “Given enough eyeballs, all bugs are shallow”).

También debo observar que con frecuencia los artículos de la Wikipedia en inglés son de más calidad que los de la Wikipedia en español. Esta observación es consistente con este modelo: la Wikipedia en inglés tiene muchísimos más artículos (al día de hoy 1.633.720), y por lo tanto, muchísimos más wikipedistas que la versión en español.

Así que podemos pensar que el crecimiento cuantitativo de la versión en español, también debería ir acompañado de un crecimiento en calidad.

Actualización: hoy (14 de febrero) aparece un artículo en Barrapunto donde se menciona que muchas personas en la comunidad están cuestionando si el modelo de la Wikipedia sirve para producir artículos de calidad.

Otra actualización (18 de febrero): Quiero recomendarles el muy intersante video de Florence Devouard, presidente de la fundación Wikimedia, hablando durante la lift conference 2007 en Ginebra. En el video Florence habla de los ideales de la Wikipedia (“Imaginen un mundo en el cuál cualquier ser humano puede acceder a todo el conocimiento humano”), y advierte sobre la urgente necesidad de donaciones para que la Wikipedia pueda funcionar (según dice: actualmente la fundación Wikimedia sólo tiene el dinero necesario para asegurar la continuidad del funcionamiento de los servidores sólo por tres meses). También pueden ver esta entrevista que un blogger le hizo a Florence.

Actualmente los artículos de la Wikipedia no tienen ningún tipo de publicidad, aunque la Wikipedia es el décimo sitio más visitado de la red. Hoy Barrapunto se hace eco del debate sobre si la Wikipedia debería aceptar incluir publicidad (aunque sea mínima) en sus páginas, y con ello resolver sus problemas financieros. Si Wikipedia podrá continuar con su actual modelo de financiamiento, basado en donaciones individuales, es quizás el más acuciante de los interrogantes que se abren sobre su futuro.

Publicado en Wikipedia. 2 Comments »

Las “guerras de distribuciones” son un clásico de la comunidad de software libre, y suelen originar interminables flames en listas de correo. Dejando de lado los fanatismos por una u otra distribución, las comparaciones entre ellas son útiles para quienes tienen que elegir una distribución para instalar en su equipo.

En mi opinión, no existe una distribución que sea mejor que otra en todos los casos, sino que cuál es la mejor distribución en cada caso depende de las necesidades y preferencias personales.

Hace poco encontré leí un post en Libertonia que comparaba Gentoo con Debian. Como soy usuario de ambas distribuciones (tengo máquinas que corren una y la otra), me gustaría dar mi opinión al respecto.

Cuando entré en el mundo de Linux, allá por 1997, mi primera distribución fue Slackware. Después fui probando otras: RedHat, Conectiva, … Hasta que finalmente descubrí Debian. Probablemente esto sea inevitable: uno tiene que probar hasta encontrar la distribución que mejor le va.

Lo que me atrajo de Debian no fueron sólo sus aspectos técnicos, sino más bien su clara identificación con la filosofía del software libre: su contrato social (aunque la nota de Libertonia diga que estas cosas no interesan a los usuarios, esto no es verdad), su política de no ocultar los problemas, el hecho de que es soportado por su comunidad de usuarios, etc.

En cuanto a lo estrictamente técnico, algunas características destacables de Debian son:

* Su alto nivel de confiabilidad, estabilidad y estandarización.

* Excelente documentación. Muy completa.

* Posee un poderoso sistema de actualización de paquetes que es muy fácil de usar (apt-get).

* El repositorio de paquetes de Debian es posiblemente el más amplio que existe. Es por lejos, la distribución más completa.

*Un sistema de configuración de los paquetes coherente y poderoso (debconf).

* Un excelente instalador (Personalmente prefiero los instaladores en modo consola, ya que no dependen de que uno pueda configurar correctamente la placa de video para funcionar). La principal virtud del instalador de Debian es que uno puede hacer las cosas automáticamente si quiere, pero también puede controlar que está pasando e incluso cambiar a otra terminal virtual y ejecutar el comando que uno quiera.

Estos y otros aspectos hacen de Debian en mi opinión una de las mejores distribuciones en formato binario. Sin, embargo la estabilidad y la confiabilidad de Debian, tienen un precio: los paquetes de la versión estable de Debian suelen estar muy desactualizados (aunque cuando salga su próxima versión, Etch será bastante actualizada, al menos durante un tiempo). Por ello, quizás Ubuntu o GnuLinex (distribuciones derivadas de Debian) sean mejores alternativas para máquinas de escritorio (y son quizás más amigables para el usuario final).

Lo malo es que el sistema de dependencias de Debian es muy estricto. Especifica cosas como: el paquete X depende de la versión Y de la librería Z. Esto desde luego, es necesario para lograr que un sistema que se distribuye en formato binario sea realmente estable.

Los dolores de cabeza con Debian empiezan cuando uno por ejemplo tiene un sistema que corre la versión estable de Debian y necesita instalar un paquete en una versión diferente de la estable. (Claro que uno puede actualizar todo el sistema a “testing” o “unstable”, pero ¿poqué actualizar todo un sistema que funciona bien a una versión de prueba o inestable por un sólo paquete?. Además ello es claramente inaceptable en un sistema “en producción”). Por ejemplo me sucedió que necesitaba instalar una versión más actualizada del X porque la que venía con Debian no soportaba mi placa de video.

Ahí las cosas se complican: puede suceder que uno pueda, si las dependencias lo permiten, instalar la versión en “testing” (prueba) o que uno encuentre un backport. Pero si el paquete tiene dependencias, muchas veces es necesario recompilarlo para que funcione (o incluso modificarlo a mano, porque algunas dependencias pueden ser imposibles de satisfacer). No hay nada que hacerle: el código fuente es muchísimo más portable que los binarios.

Como me gusta probar software nuevo, pronto me encontré compilando un montón de paquetes. Esto también sucede cuando uno programa, porque para desarrollar software frecuentemente uno necesita la última versión de las librerías que va a utilizar.

Fue entonces cuando descubrí Gentoo: una distribución basada en código fuente. Gracias a su herramienta portage, automatiza el proceso de compilación, pero permite que el usuario especifique que opciones desea habilitar y cuales no para cada paquete (por medio de los parámetros USE), e incluso que optimizaciones debe usar el compilador (permitiendo por ejemplo generar paquetes optimizados para una determinada arquitectura, mientras que los paquetes binarios de Debian vienen compilados para intel 386, por lo que no aprovechan al máximo las capacidades de los procesadores modernos).

Al igual que Debian, Gentoo está soportada por su comunidad, y tiene un Contrato Social similar al de Debian.

La diferencia esencial es que cuando uno instala una distribución en formato binario, cede buena parte del control de su equipo a los desarrolladores de esta distribución (Ojo, esto no es necesariamente malo: si uno es un usuario no técnico, es mucho mejor confiar en técnicos expertos que hacerlo uno); en cambio con Gentoo retiene al máximo el control de su equipo: puede especificar exactamente que versión de un paquete desea instalar. Pero el control conlleva responsabilidades: con Gentoo hay frecuentemente que leer la documentación en detalle para ver como funciona cada cosa, y configurar los paquetes editando los archivos de configuración a mano. (De todos modos, la cesión del control de nuestro equipo que implica el uso de distribuciones binarias tiene una diferencia esencial si se trata de software libre, a la que ocurre al usar software privativo. Dicha cesión no es irrevocable. En cualquier momento en que lo necesitemos, podemos tomar el control en nuestras manos: descargar el código fuente, compilarlo y modificarlo)

Para desarrolladores y usuarios expertos, Gentoo viene como anillo al dedo. Permite hacer exactamente lo que uno quiera con su sistema, de una forma sencilla. Pero sólo la recomendaría para ellos: para el usuario no técnico, que lo último que quiere es tener que compilar cada paquete desde el código fuente y configurarlo editando los archivos de configuración a mano, Gentoo es una pesadilla (entre otras cosas: porque es muchísimo más complicado de instalar que Debian).

Otra situación en la cuál Gentoo puede ser útil, es como metadistribución, que sirva de partida para generar distribuciones en formato binario. Es por ejemplo, lo que hace la gente de Ututo.

En resumen: No hay una distribución que pueda ser todo para todos, o que sea universalmente mejor que otra. Cada cuál debe elegir la que más le guste teniendo en cuenta sus necesiadades y preferencias personales.

Hace poco comentábamos sobre que había tantos lenguajes de programación que uno puede entrar en crisis a la hora de elegir el más adecuado.

Ahora estoy tratando de elegir un sistema de control de versiones para mis proyectos personales, y me sucede algo similar. Existen tantos sistemas de control de versiones que no sé cuál es el más adecuado. Aquí pueden ver una comparación entre varios de elllos. (Incluso algunos proyectos como Axiom, no llegan a decidirse por uo de ellos y ofrecen su código fuente a través de varios de ellos).

Los sistemas de control de versión son un componente esencial en el desarrollo del software libre. Los sistemas de control de versiones hacen posible que varios programadores compartan el código en el que están trabajando a través de la red. Cuando un programador hace una modificación, ella está inmediatamente visible para los demás desarrolladores. Además el sistema lleva el control de las versiones del proyecto, y es posible pedirle algo como “quiero ver el código fuente del proyecto tal como estaba el viernes a las tres de la tarde”. Usando CVS, pude por ejemplo, colaborar en proyectos de software libre como Bluefish o Yacas, trabajando con programadores en Holanda o en Rusia, a los cuáles nunca he conocido personalmente.

El interés de los sistemas de control de versiones no está limitado a los programadores. También son útiles para otros propósitos: por ejemplo los científicos podemos usarlos para escribir un trabajo (paper) en colaboración.

En un comienzo CVS era el sistema de control de versiones más utilizado. Sin duda, CVS es una herramienta que ha sido muy útil durante muchos años, y todavía es utilizada por muchos proyectos de software libre. Representó un gran avance sobre la era pre-CVS, donde el desarrollo se hacía intercambiando parches (patchs) que se aplicaban a mano, en un proceso engorroso y propenso a los errores.

Sin embargo, con el tiempo, se han empezado a notar sus limitaciones. Para mí las más notables son tres: CVS no soporta mover o renombrar archivos o directorios conservando la historia; tampoco soporta copiar un archivo conservando la historia, y finalmente las operaciones de escritura al repositorio (commits) no son atómicas.

Después apareció Subversion, un proyecto que se propuso superar las deficiencias de CVS pero conservando su filosofía básica, y realmente creo que es una gran herramienta. De a poco, la mayoría de los grandes proyectos, se están moviendo a Subversion: GCC, KDE y ahora Gnome. También Sourceforge ofrece ahora soporte para Subversion.

Sin embargo, el modelo de desarrollo centralizado de CVS y Subversion (que requiere un repositorio central al que los desarrolladores tengan acceso a través de la red) no es adecuado para muchos propósitos.

Se han desarrollado por ello, sistemas de control de versiones distribuidos, que no requieren un repositorio central como por ejemplo: SVK (construido sobre Subversion), GNU Arch, Mercurial, Monotone , Darcs, Bazaar y Git (creado por el mismísimo Linus Torvalds para manejar el código fuente del núcleo de Linux; cuando su elección del sistema privativo Bitkeeper mostró haber sido un claro error).

Seguramente voy a elegir algun sistema de control distribuido porque tengo varias computadoras que uso para desarrollo que no tienen conección permanente a la red, hasta ahora el que más me seduce es Mercurial. Entre otras cosas por estar escrito en Python. Si quieren dejarme algún consejo al repecto en los comentario, es bienvenido.

Por suerte existe Tailor, una herramienta para convertir entre los diferentes sistemas de control de versiones. Prové convertir mi repositorio de Subversion a Mercurial sin éxito (Tailor parece confundido por un directorio que borré de mi repositorio), pero sí funcionó convertirlo de Subversion a Darcs.

Actualización:  Quiero recomendarles este video de  Bryan O’Sullivan, uno de los desarrolladores pincipales de Mercurial, hablando en las Google TechTalks sobre este proyecto.

Publicado en Desarrollo. 2 Comments »