Porque linux no puede vencer en el escritorio?
 

Porque linux no vence en el escritorio?


 http://img1.jurko.net/wall/paper/linux-penguin.jpg


A pesar del éxito de Linux en áreas como servidores y ahora posiblemente en celulares, la victoria de Linux en el escritorio es el santo grial que nunca ha podido ser alcanzado, pero ¿por que no? que es lo que Linux hace o deja de hacer que no le permite lograr ese objetivo.

Hace 10 años el considerar un servidor Linux para uso corporativo era aun mirado de mala forma, se decía que era un sistema realizado por novatos que carecía de la seriedad necesaria para poder entrar al mercado corporativo, esto cambio dramáticamente con los años, hoy en día de los 500 servidores más poderosos del mundo, 439 (88%) corren bajo sistemas Linux y dentro del mercado de servidores corporativos, la cuota Linux se estima entre 17% y 34%, pero ¿por que no se ha podido traspasar ese éxito a otras áreas como el escritorio?

kde4_1_2_cube

Analicemos entonces algunas de las razones que se esgrimen, pero no entraremos en el “de quien es la culpa“, desde el punto de vista del usuario final, de quien sea la culpa, es lo de menos.

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

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.

wine-doorsUna 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

Cliente de Build Services compilando Mono OSC

Adicionalmente el sistema permite que no solamente se soporten muchas distribuciones de forma simultanea, sino que además se pueden soportar versiones anteriores de una misma distribución, con ello es relativamente simple que por ejemplo el equipo de Firefox pueda tener binarios actualizados para las principales distribuciones y además soportar distribuciones más antiguas.

Se puede mantener además con relativa facilidad versiones “portables” de los programas, con lo cual nos evitamos los problemas que ocasionan las dependencias, especialmente en aquellos que no cuenta con conexión a internet y suelen descargar en otra parte los programas en .deb o .rpm, para descubrir que les falta alguna librería y luego otra y otra.

Al mismo tiempo se facilita la tarea a quien necesite compilar drivers en versiones del kernel más antiguas, por que es usual que con cada salida del kernel se mejora el soporte de hardware, pero eso no sirve de mucho cuando estas comprando hoy un hardware nuevo para instalarlo en un sistema de hace un año.

Finalmente entonces logra que el proceso de construcción quede más en manos del desarrollador directamente, quien además es el más capacitado para solucionar los problemas que puedan surgir al compilar, esto hace que la distribución se pueda enfocar más en mejorar y solucionar problemas propios de su distribución y no conflictos con librerías de un programa en particular que se soluciona de la misma manera en distintas distribuciones de forma paralela.

cnrEsto se puede sumar el uso de un instalador gráfico común que este linkeado directamente con Build Services y pueda por tanto agregar no solo fuentes de instalación oficiales, sino además de terceros como pueden ser Firefox, NVIDIA, SAP, etc. Una herramienta interesante que ya existe (aunque no linkeada a Build Services) es CNR, una aplicación desarrollada por Linspire que tiene la gracia de que además puede incluir información como popularidad de un programa, pantallazos, links a reviews e incluso tiene la posibilidad de poder agregar programas pagados con lo cual se abren las puertas a las empresas dentro del mundo Linux. El modelo ya ha sido probado con sistemas similares con la tienda de aplicaciones del iPhone que hoy por hoy está siendo replicada por los demás actores en el mundo celular, incluso Ubuntu estáreinventando la ruedadesarrollando su propia versión de CNR llamada AppCenter, por que no abrazar entonces una tecnología que ya existe y que además ya ha probado su éxito, para que gastar tiempo y esfuerzo en aplicaciones propias que no entregan mayor valor agregado.

Ambas cosas al unisono, mantienen la ventaja que tiene Linux con sus múltiples versiones o distribuciones, al adaptarse mejor a distintas necesidades, pero al mismo tiempo elimina la desventaja en dicha fragmentación o por lo menos parte de ella.

Siguiendo nuestro consejo, no es seguro que Linux conquiste el escritorio, todo lo anterior solo es una opinión más como las muchas que abundan en internet, y si es probable que de seguir nuestro consejo, parte de las ventajas comparativas de algunas distribuciones, con respecto a otras distribuciones Linux disminuiría, pero es mejor comer 10% de un pastel grande que solo la mitad de una migaja y con 1% o 3% de participación de Linux en el escritorio, lo único que existe hoy son migajas y tal ves es momento de pensar en equipo.






Añadir comentario acerca de esta página:
Tu nombre:
Tu mensaje:

 
  Hay 587815 visitantes (2629524 clics a subpáginas)  
 
=> ¿Desea una página web gratis? Pues, haz clic aquí! <=
programas-programas programas-programas
Banner de la pagina: