Aplicaciones portables ¿un mito?

Acabo de leer el artículo “Welcome to the Jungle” que habla de la segmentación y la falta de estándares en Linux, en concreto para el audio. El artículo tiene ya un tiempo (mayo de 2005), pero lo cierto es que las cosas han cambiado poco o muy poco.

Hay gente que dice que la fragmentación es inherente al software libre. Yo creo que una cosa es que puedan existir N-mil extensiones sobre un estandar y otra que no exista un estandar.

En barrapunto están comentando unas declaraciones de Ben Goodger, desarrollador de Google Chrome, en las que se queja precisamente de eso, de la falta de estándares en Linux. Lógicamente al ser barrapunto, más que comentar se lanza mierda unos a otros, pero lo cierto es que la discusión es interesante.

Suelo escribir código en .Net (C# normalmente) y Java, y es cierto que ambos prometen portabilidad. De hecho, ambos te venden que son perfectamente capaces de hacer todo, que el usuario no notará diferencia con aplicaciones “nativas”, que todo será color de rosa y que antena 3 no hará contraprogramación cuando emitan tu programa favorito. Tal y como yo lo veo, lo único que tienen esperanzas de conseguir es lo de antena 3.

Cuando un programador (y me incluyo) tiene que hacer la aplicación X tiene que tomar varias decisiones (que si lenguaje, librerías, IDE, etc…). Una de las cosas más difíciles es como hacer que sea portable. Normalmente que una aplicación sea portable significa que el programador va a trabajar con un número de recursos muy limitado ¿por qué? Sencillo, tendrá que usar únicamente aquellas funciones que estén implementadas en todas las plataformas. En otras palabras, vas a escribir hasta los cuadros de diálogo :P

Como usuario me molesta bastante porque una de las primeras cosas que un programador se pasa por el ***** digo, que se salta, son las guías de estilo. Ejemplo, yo no soy capaz de cerrar Spotify en Windows a la primera. ¿Por qué? Porque la aplicación (que canta a MacOS X) ha decidido que el icono de aplicación (ese que está en la esquina superior izquierda de todas las ventanas en Windows) era prescindible (MacOS X no lo tiene), así que se lo han cepillado. Yo cierro las ventanas haciendo doble click en su icono de aplicación…. claro, Spotiy no, porque no tiene.

Personalmente creo que deberíamos olvidarnos de las aplicaciones portables. Una aplicación integrada en el sistema es más productiva que una que no lo está, y una integración sólo es viable si la aplicación no es portable.

Es cierto que hay ejemplos de aplicaciones que funcionan muy bien en diferentes plataformas (VLC, Firefox, etc..) pero no deja de ser una verdad a medias. Por poner un ejemplo, ninguno de los dos toma el proxy de mi sistema, tengo que especificárselo a cada aplicación, o que Firefox no muestre una miniatura por pestaña en Windows, sino una por ventana (lo cual es… inútil).

Aunque hay casos más sangrantes, como las empresas que se empeñan en decir que no necesitan hacer un porte porque sus productos funcionan bajo Wine. Wine puede ser muchas cosas, pero dista mucho de ser transparente… más bien es una cosa ahí tirada que tiene una integración nula y unos resultados mediocres. Está bien para un apuro, pero eso es todo.

Hoy en día hay tres sistemas operativos mayoritarios (Windows, MacOS X y Linux) y perseguir la creación de una aplicación que funcione en todas ellas es dejar con mal sabor de boca a las tres.

Por Carballude

Me llamo Pablo Carballude González, soy graduado en computación con master en HCI y Seguridad Informática. Actualmente trabajo para Amazon en Seattle como Software Developer Engineer. Soy de esas personas que no saben si los textos autobiográficos deben ser en primera o tercera persona. Lo intenté en segunda, pero no le entendí nada :P

7 comentarios

  1. Luego vienen problemas derivados de muchas más pijadas… del estilo de int *pointer = NULL, luego casca en algunas comprobaciones porque NULL != 0 en muchos sistemas. En muchas guías de estilo, lo primero que te dicen (incluido en el libro de Stroustrup de C++) es que los punteros se inicializan a 0, y no a NULL para mayor portabilidad.

    Y eso te digo en código normal y corriente. Si te pones a ventanas, donde buscas un compromiso de buena integración, rendimiento, usabilidad… la repanocha.

    En mi opinión, el código del «núcleo» de una aplicación debe ser lo más portable posible. El envoltorio (las ventanas si es gráfica), debe ser lo más intregado en el sistema posible, sino te encuentras con cosas como tú comentas.

    Creo que cada vez se tira más a aplicaciones web, además de otras muchas razones, por esta: la portabilidad. Si escribes bien tu aplicación web, programas una vez y se ve igual en todos los navegadores (bueno, más o menos igual xD).

    ¿Tú que opinas?

  2. Lo cierto es que uso varias aplicaciones web, pero todas adolecen de lo mismo… tienen una integración baja/nula con el sistema.

    Además, mientras que dos motores puedan renderizar las páginas de forma distinta, no creo que podamos usar aplicaciones web de forma confiable.

    Portar el núcleo de la aplicación puede sonar bien, pero me da que no es tan fácil como parece. ¿Cómo portas un juego que usa DirectX? ¿Una aplicación que usa IE?

  3. Para aplicaciones web, la integración con el sistema no se consigue, por supuesto. Pero se tiene la «portabilidad».

    Los motores de renderizado pueden hacer de las suyas, pero si sigues los estándares a rajatabla ese problema no es muy acuciante. Ahora que claro, si te ciñes al estándar pierdes funcionalidad, es la pescadilla que se muerde la cola.

    Lo de portar el núcleo de la aplicación (lo que es la funcionalidad pura y dura), en el ejemplo de una aplicación que usa IE, lo veo más que posible.

    En el caso de DirectX es cierto, pero si escoges DirectX es que no estás pensando en portabilidad más que a otros sistemas Windows (y a veces ni eso si la versión de DirectX es muy moderna y la versión de Windows antigua).

    Si se hubiera escogido OpenGL (que vale, que su API es un infierno pero tiene implementaciones en los SSOO más importantes) tendrías mayores probabilidades de obtener la tan deseada portabilidad a otros SSOO.

    Es como si yo quiero que mi código sea portable a Linux y uso la API de Win32, algo falla ahí.

  4. ¿Queremos portabilidad a costa de integración? Yo al menos no.

    Ahí está… los estándares están muy por detrás de las necesidades del mercado. Además, me parece que son muy vagos (en cuanto a poco específicos)… claro que es una impresión.

    Imagino que alguien que usa DirectX está pensando en que el tiempo de desarrollo será menor que con otras tecnologías y la propensión a fallos menor (aunque esto último ya es más discutible). Mientras no exista un estandar para esas cosas cada uno hará una cosa distinta. Yo suelo tener problemas con los juegos que usan OpenGL en Windows… aunque no se por qué.

  5. Siempre hay algo hay que sacrificar. Si quisiéramos que fuera totalmente portable e integrado en la mayoría de los sistemas operativos, debería de haber una API común, bien hecha… vamos que es una utopía, teniendo en cuenta los intereses comerciales que hay por el medio.

    Los estándares están detrás de las necesidades del mercado, precisamente por las propias necesidades. Me explico, los estándares se suelen aplicar a «estándares de facto», tecnologías consolidadas de varios fabricantes y similares entre sí, etc. No se puede estandarizar un producto o tecnología sin saber si es aceptada (o será aceptada) por el mercado.

    Por ejemplo, en el caso de productos industriales, se suele ver, en base a una necesidad concreta de un estándar en un área, qué características comunes tienen todos los fabricantes, cuáles parecidas y cuales son totalmente distintas. En las negociaciones para sacar el estándar final, el fabricante con mayor cuota de mercado suele conseguir que se tire más hacia su parcela.
    Pero siempre se deja el margen abierto (o confuso, si prefieres llamarlo así) para que otros fabricantes implanten sus propias soluciones y todos salgan «ganando». De ahí, que haya, por ejemplo, tarjetas Wifi que tiran mucho mejor con productos del mismo fabricante, pese a que es compatible con el resto y «supuestamente» sigue el estándar.

    Por tanto, el estándar siempre va por detrás. En cierto modo, se deja libertad al mercado para que decida qué tecnología se imponga y luego se estandariza en torno a ella dejando margen para que los fabricantes puedan realizar cambios «menores». (Huelga decir, que luego hay empresas grandes que a golpe de talonario meten sus propios productos en un estándar y se pasan todo lo que te cuento por el forro)

    Siento el tostón de post, pero creo conveniente contarte esto jeje

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *