Compatibilidad de hardware y dificultad en la instalación

Me parece que estas razones son probablemente las que con mayor frecuencia se repiten, sin embargo como motivos del por que el poco éxito de Linux en el escritorio, me parece que son más bien un mito.

A pesar de que Linux posee muchos más drivers que Windows, en el mundo x86 la compatibilidad es menor, es mucho más común en Linux que en Windows escuchar hablar de dificultades para hacer funcionar la aceleración 3D de una VGA, un dispositivo WiFi o una cámara web, es verdad que en Windows es un poco más complicado hacer funcionar el hardware, ya que en general presenta pocos drivers y por tanto es necesario instalarlos aparte, en cambio en Linux los drivers vienen con el sistema por lo cual en la mayoría de los casos no es necesario hacer nada, sin embargo cuando el hardware no es detectado por el sistema en Linux y es necesario instalar el driver de forma manual, la dificultad es mucho mayor que en Windows y además en ocasiones incluso no hay solución.

¿Por que digo entonces que es un mito?

Cuando vemos los tres sistemas más populares en el escritorio, se observa que el primer lugar en compatibilidad de hardware lo tiene Windows, seguido de Linux y en último lugar Mac OSX, luego cuando vemos la participación de mercado en el escritorio (o por lo menos una aproximación a la misma), se observa que el primer lugar lo tiene Windows, seguido de Mac OSX y luego Linux, por tanto Mac OSX con menor compatibilidad vence a Linux, aquí algunos podrían argumentar que Mac vende su sistema operativo con hardware y por tanto en la practica su compatibilidad es absoluta, sin embargo cuando se analiza con más detalles las estadísticas, se observa que alrededor del 50% de la participación de Mac OSX en USA corresponde a instalaciones en PCs comunes y corrientes (hackintosh), el cual presenta una compatibilidad mucho más pobre que Linux, existe una lista extensa de hardware que simplemente no es posible hacer funcionar en un hackintosh y sin embargo la sola participación de este limitado hackintosh sin tomar en cuenta la de Mac OSX oficial a través de Apple, es mucho mayor que la de Linux.

¿Que es lo que cambia? La diferencia a nuestro juicio, en este aspecto en particular, es que en el caso de Mac OSX, existe mucha mayor claridad de que hardware es compatible y que hardware es incompatible, con Linux muchas veces el tema es más aleatorio, hardware que funciona bien para algunos, no funciona para otros. Yo tengo absoluta claridad por ejemplo que el WiFi de mi notebook no sirve con Mac OSX, sin embargo y a pesar de utilizar Linux desde hace años, no tengo seguridad si cuando instalo una distribución de Linux funcionará bien mi WiFi, de la misma forma estoy claro que WiFi USB podría adquirir para que tenga soporte en Mac OSX, pero de nuevo no tengo seguridad de cual funciona bien en Linux (en cualquier distribución).

Adicionalmente Mac OSX provee un valor agregado adicional, el asunto no es solamente lograr que la gente pruebe tu sistema, francamente intuyo que más personas han probado Linux que las que han probado un hackintosh, sin embargo cuando se ve la participación, esta se suele medir en base a lo que los usuarios están usando para navegar y no en base a lo que se ha instalado en el disco duro, luego la gente que prueba un hackintosh tiene una mayor tendencia a quedarse y usar el sistema que la gente que ha probado Linux.

La segunda parte del mito corresponde a la dificultad en la instalación, esto me parece que si es un mito sin segundas interpretaciones, la instalación de un Linux moderno es mucho más simple que hace 5 o 10 años, no requiere de avanzados conocimientos  y además es considerablemente más fácil que un hackintosh, por tanto nuevamente podemos utilizar el argumento anterior y ver que hackintosh aun con un sistema más difícil de instalar es mucho más usado.

Falta de aplicaciones comerciales y juegos

Este punto es probablemente lo más complejo de resolver, para que una aplicación comercial soporte nuevas arquitecturas, es necesario que la misma invierta en desarrolladores que porten la aplicación con todas sus funcionalidades, pero además que realicen mantenimiento y soporte sobre la nueva arquitectura, para ello es evidente que el esfuerzo financiero debe ser recompensado con un beneficio económico actual o potencial superior, de lo contrario no tiene sentido para la empresa realizar dicha acción. Si Linux no tiene una participación que garantice dicho beneficio económico entonces la empresa simplemente no invertirá en soportar la arquitectura.

Oblivion ejecutado en Linux con Cedega

En el caso de muchas aplicaciones comerciales, existen alternativas de código abierto en Linux que proveen de mayor o menor manera las mismas funcionalidades, por tanto muchas veces este problema no es tan importante desde el punto de vista de satisfacer las necesidades del usuario, tal ves el mayor problema es lograr que el usuario se acostumbre a la nueva aplicación,  sin embargo existen algunas aplicaciones cuyas funcionalidades o características no son resueltas por aplicaciones de código abierto, los usuarios que utilizan dichas aplicaciones pertenecen por tanto a un nicho no cubierto por Linux, tal ves el más grande de ellos sea el sector gamer, ya que aun cuando algunos juegos están soportados en Linux, muchos de ellos no lo están o lo están a medias (utilizando aplicaciones que entregan las apis de Windows como Wine o Cedega), además su instalación y configuración no es sencilla.

¿Que puede hacer Linux para mejorar este aspecto?

Es evidente que no puede llegar y aumentar su participación, eso no es un factor sobre el cual se tenga control, pero lo que si puede hacer es disminuir los costos asociados al soportar aplicaciones comerciales en Linux, con ello más empresas se podría ver interesadas, ya que no les implica mayores esfuerzos financieros.

Una de las formas de lograr esto es a través del proyecto Wine que provee las APIS de Windows sobre Linux y por tanto una aplicación que corre en Windows, puede correr dentro de Linux o cualquier otra plataforma soportada por Wine, pero Wine es complicado muchas veces de configurar y además la mayoría de las distribuciones no lo integran adecuadamente con el sistema, cuando haces por ejemplo click a un archivo “.exe” muchas veces se abre con un editor de texto, cuando debería a mi juicio abrirlo con Wine, adicionalmente existen aplicaciones gratuitas que facilitan enormemente la instalación de aplicaciones con Wine, como es el caso de Wine Doors, pero las distribuciones no parecen darle la importancia de que deberían y en general está aplicación, no solo no viene por defecto en las instalaciones, sino que además está soportada solamente por un pequeño grupo de personas, pero no por una empresa.

La razón que tienen muchos para no dar mayor importancia a Wine, es que si Linux soporta las APIS de Windows, entonces las empresas no se verán interesadas en desarrollar aplicaciones nativas, cabría preguntarse ¿Como les ha resultado esto hasta ahora? Francamente me parece que esa tesis se ha demostrado errónea, las empresas no desarrollan aplicaciones para Linux, simplemente por que no tiene la participación suficiente para justificar el gasto.

Falta de prolijidad en productos “finales”

Si alguna vez a usted le dijeron que Linux nunca se pegaba o caía, pues le mintieron. Linux es un sistema operativo extremadamente estable, pero básicamente cuando se trata de funciones de servidor, si tiene un servicio corriendo sobre Linux, es muy difícil que el mismo se caiga, sin embargo eso no quiere decir que las aplicaciones en Linux sean así de estables, especialmente cuando hablamos de aquellas con entorno gráfico y sobre todo si son poco usadas, la gracia es que incluso cuando dichas aplicaciones se caen, los servicios y el núcleo del sistema seguirán corriendo.

Aquí no quiero tampoco generalizar, hay aplicaciones y distribuciones muy bien cuidadas, además esto no suele ocurrir con las aplicaciones que incluyen por defecto en las distribuciones, sin embargo es más común de lo que debería que cuando se instala una aplicación que no viene por defecto, al ejecutarla descubras que se cae de forma inmediata.

Adicionalmente muchas veces se lanzan productos como finales, cuando en realidad están en estado beta, un ejemplo muy prominente de ello, es el reciente KDE 4.0 el cual incluso informaba en las notas de versión que no era un producto terminado, aun así muchas distribuciones lo incluyeron como escritorio, con el fin de potenciar su uso y poder tener así una gama de bugs reportados más amplia, lo cual aceleraría el desarrollo del mismo, en estricto rigor KDE 4.0 debería de haber sido marcado como alpha, de la misma forma KDE 4.1 y KDE 4.2 deberían de corresponder a KDE 4.0 beta 1 y beta 2 respectivamente, ya que aunque son más estables, no contienen todas las características anunciadas para KDE 4 y solamente el futuro KDE 4.3 podría llamarse RC (Realease Candidate).

Una forma de solucionar esto o por lo menos de filtrar un poco el asunto, es utilizar un método de certificación, en este punto perfectamente podría jugar un papel importante la Linux Foundation, la cual podría certificar aplicaciones realizando pruebas básicas de funcionalidades y estabilidad, con ello una aplicación podría no considerarse final, hasta no contar con la aprobación de la Linux Foundation.

Otra forma es no tener tanto apuro en lanzar una distribución, muchas veces las distribuciones lanzan sus productos como finales aun contando con un número importante de fallas, simplemente para cumplir con una fecha que nadie les ha impuesto, así vemos como Ubuntu por ejemplo cumple religiosamente con sus lanzamientos cada 6 meses, pero también observamos como Dell aun incluye en sus productos Ubuntu 8.04 a pesar que Ubuntu 8.10 y ahora Ubuntu 9.04 fueron lanzadas hace ya un buen tiempo, por que no quieren cambiar, en palabras de la misma Dell “por estabilidad”.

Una distribución que no cae en la presente critica es Debian ya que su sistema de construcción está pensado precisamente para evitar ese problema, ellos dividen su distribución en estable, pruebas e inestable, luego la versión inestable va pasando aplicaciones de a poco a la versión de pruebas hasta que llega un momento en está se congela y solamente se dedica a resolver fallas, lo cual da lugar finalmente a la versión estable. El proceso completo puede tomar varios  años, sin embargo el producto final es realmente estable. La falla de este sistema, es que la versión estable suele incluir software anticuado y para instalar software más reciente, muchas veces se requiere poner como fuentes de instalación a las versiones inestables que a su vez muchas veces instalan librerías que podrían comprometer el sistema completo. El otro problema o por lo menos potencial problema, es que si  comparamos la cantidad de paquetes (programas) soportados en la versión lanzada el 2002 vs la cantidad de paquetes soportados en la versión actual, vemos que el número se incremento en 212%, a ese ritmo Debian no podrá garantizar la estabilidad de todos sus programas, manteniendo tiempos de lanzamiento razonables.

Una posible solución

En varios de los problemas descritos, hemos planteado de forma conjunta soluciones a lo menos parciales para los mismos, ahora queremos realizar un planteamiento un poco más ambicioso con una propuesta que a nuestro juicio podría resolver buena parte de los problemas actuales en Linux.

Si usted desarrolla una aplicación que incluye a Linux como plataforma, tiene dos formas de lograr que está sea soportada por las distintas distribuciones, la primera es simplemente liberar el código fuente y esperar que “alguien” se tome la molestia de tomar dicho código fuente y compilarlo o bien puede realizar ese trabajo usted mismo, compilando para cada una de las distribuciones o por lo menos las más importantes. El problema evidente en esto, es que ya sea el desarrollador o el empaquetador, existirá una enorme cantidad de trabajo duplicado para tener un binario funcional en varias distribuciones, adicionalmente en muchos casos a no ser que el programa esté incluido en la rama principal, cuando se actualice el software dependiente podría romper la aplicación, por lo cual el soporte es complejo.

Luego si las principales distribuciones soportaran un sistema de compilación centralizado, en donde un desarrollador o empaquetador pudiera crear en un solo paso binarios para las principales distribuciones, sin lugar a dudas la tarea sería más simple, este lugar ya existe, fue creado en su momento por Novell/OpenSuse y ahora lo trasladó a la Linux Foundation para que no sea asociado con una distribución en particular y puede así ser adoptado por diversas distribuciones.

Cliente de Build Services compilando Mono OSC