"Si hemos programado en Windows pero estamos interesados en la programación en Linux, estos consejos resultan especialmente útiles para cambiar algunas de las ideas y minimizar el choque ocasionado por el cambio de cultura cuando encontramos diferentes ideas y formas de pensar." Noticia en inglés y en castellano aquí http://www.linuxparatodos.net/geeklog/article.php?story=20061215042035229
#3 Qué, cuando haya un problema en una de ellas y el usuario actualice, tu programa no cogerá la actualización sino que seguirá dependiendo de la vieja junto a la que lo empaquetaste y seguirá sufriendo el fallo.
También hay problemas de compatibilidad: si empaquetas dependencias tienes que empaquetarlas juntas todas porque nadie te asegura que alguna llegue a ser incompatible con una versión posterior de una dependencia "base", que tú no incluyes sino presupones que ya la tiene satisfecha el usuario.
#8 WxWidgets depende de Gtk, si una versión de gtk posterior es incompatible con la que espera la wx que usas te caes con todo el equipo igual. Es añadir una dependencia más.
Que el programa se distribuya en Japón directamente o no tiene poca relevancia. En Linux un japonés (o un hebreo, o un coreano, o un chino o, etc. etc.) incluir el método puede añadir el método de escritura y todas las aplicaciones pasan a soportar japonés, todas salvo las que distribuyamos con nuestro propio gtk.
Y el que dice modos de entrada dice locales o temas.
#5 El enfoque de incluir todo no funciona porque muchas dependencias no se pueden incluir.
Por ejemplo en Linux Qt y Gtk tienen temas y métodos de entrada en forma de biblioteca binaria. Si incluyes Gtk en el paquete tienes que incluir los propios temas (con lo que no tendrá el mismo aspecto que el resto de las aplicaciones del usuario) y los métodos de entrada. Luego los metodos de entrada, del japonés por ejemplo, dependen de un servidor externo de conversion (anthy, canna...) con el que hablan a través de una biblioteca determinada, así que habría que incluirlos también y, así, tirando del hilo, al final tienes que distribuir tu programa con un Linux completo qué, bien mirado, tampoco es una tonteria: Oracle quiere hacer algo parecido para distribuir su base de datos
Klik es algo parecido a eso pero sólo se incluyen una parte de las dependencias y esperan que el resto esté instalado (las X, KDE...). Si no lo está... Pues falla.
Habrá que resolver el infierno de las dependencias, porque dá muchos problemas y gasto en tiempo que podría emplearse en ser más creativos. ¿Existe alguna idea sobre cómo hacerlo?, ¿quizás una idea parecida a LinuxBios?.
Pues si, conozco algo el citado infierno. Lo único que se me ocurre es que mi aplicación incluya todas las dependencias, y que cuando haya un problema en alguna de ellas, sacar una nueva versión de mi programa que incluya la actualización.
Todo menos desanimar a los nuevos usuarios de Linux con tener que descargarse chorrocientas bibliotecas cada una de las cuales tiene a su vez chorrocientas dependencias.
La parte más pesada para nosotros es desarrollar programas fáciles de usar, pero si lo hacemos, nos evitaremos una pesadez mayor contestando miles de preguntas sobre cómo se hace esto o aquello.
P.D. Soy exageradillo.
Comentarios
#3 Qué, cuando haya un problema en una de ellas y el usuario actualice, tu programa no cogerá la actualización sino que seguirá dependiendo de la vieja junto a la que lo empaquetaste y seguirá sufriendo el fallo.
También hay problemas de compatibilidad: si empaquetas dependencias tienes que empaquetarlas juntas todas porque nadie te asegura que alguna llegue a ser incompatible con una versión posterior de una dependencia "base", que tú no incluyes sino presupones que ya la tiene satisfecha el usuario.
Es lo que en Windows se conoce como el Dll-Hell. http://es.wikipedia.org/wiki/DLL_Hell
#8 WxWidgets depende de Gtk, si una versión de gtk posterior es incompatible con la que espera la wx que usas te caes con todo el equipo igual. Es añadir una dependencia más.
Que el programa se distribuya en Japón directamente o no tiene poca relevancia. En Linux un japonés (o un hebreo, o un coreano, o un chino o, etc. etc.) incluir el método puede añadir el método de escritura y todas las aplicaciones pasan a soportar japonés, todas salvo las que distribuyamos con nuestro propio gtk.
Y el que dice modos de entrada dice locales o temas.
Y si hemos programado en Linux y nos obligan pistola en mano a portar a Windows este nos enlace vendrá bien: http://msdn2.microsoft.com/en-us/library/ms811903.aspx
Más referencias en: http://tinyurl.com/y8wy7j (vaya, parece que menéame no acepta enlaces con paréntesis. Lo paso por tinyurl)
#5 El enfoque de incluir todo no funciona porque muchas dependencias no se pueden incluir.
Por ejemplo en Linux Qt y Gtk tienen temas y métodos de entrada en forma de biblioteca binaria. Si incluyes Gtk en el paquete tienes que incluir los propios temas (con lo que no tendrá el mismo aspecto que el resto de las aplicaciones del usuario) y los métodos de entrada. Luego los metodos de entrada, del japonés por ejemplo, dependen de un servidor externo de conversion (anthy, canna...) con el que hablan a través de una biblioteca determinada, así que habría que incluirlos también y, así, tirando del hilo, al final tienes que distribuir tu programa con un Linux completo qué, bien mirado, tampoco es una tonteria: Oracle quiere hacer algo parecido para distribuir su base de datos
Klik es algo parecido a eso pero sólo se incluyen una parte de las dependencias y esperan que el resto esté instalado (las X, KDE...). Si no lo está... Pues falla.
entre botijo y lavadora..se me da mejor el botijo
Habrá que resolver el infierno de las dependencias, porque dá muchos problemas y gasto en tiempo que podría emplearse en ser más creativos. ¿Existe alguna idea sobre cómo hacerlo?, ¿quizás una idea parecida a LinuxBios?.
- NO EMPAQUETAR DEPENDENCIAS
¿Y si lo hago qué pasa?. :-
Pues si, conozco algo el citado infierno. Lo único que se me ocurre es que mi aplicación incluya todas las dependencias, y que cuando haya un problema en alguna de ellas, sacar una nueva versión de mi programa que incluya la actualización.
Todo menos desanimar a los nuevos usuarios de Linux con tener que descargarse chorrocientas bibliotecas cada una de las cuales tiene a su vez chorrocientas dependencias.
La parte más pesada para nosotros es desarrollar programas fáciles de usar, pero si lo hacemos, nos evitaremos una pesadez mayor contestando miles de preguntas sobre cómo se hace esto o aquello.
P.D. Soy exageradillo.
Me dá a mí que con las Wx se resuelve el primer problema, y si no tienes que distribuir tu programa a Japón...
La web de linuxparatodos.net no funciona (ergo, el enlace tampoco funciona).