Pues bien, primero Android con su formato APK y ahora un par de proyectos buscan cambiar esto con el objetivo de que se puedan instalar aplicaciones en distribuciones Linux sin pasar por un repositorio, sino instalando un paquete que integre todas o casi todas sus dependencias y sea utilizable en cualquier distribución sin recompilar.
#3 Bueno pero aquí añaden seguridad (checksums, firmas), posibilidad de tienda de aplicaciones, , estándar de árbol de directorios, múltiples versiones y cambiar entre ellas más fácilmente.
#18 Entonces deberías explicarte mejor.
Si no has dicho lo que has dicho, es que tu forma de expresarte ha sido equivocada.
Has dicho que añade cosas que realmente ya están.
Tiene sentido para algunos paquetes... pero la mayoría del sistema debe estar basado en repositorios de toda la vida, por seguridad, por rendimiento, etc.
#25Primero en ningún momento hablo de tener varias copias de una misma librería en sí
Si lo haces.
sino que hablaba que respecto a desinstalar un programa es mucho más fácil, que tener que andar revisando si una librería es compartida por otro programa. Y en cualquier caso eso debería ser cosa del programador de la aplicación y del propio S.O para que no borre algo que se necesite.
Ese es tu problema si utilizas windows, aprende a usar gestores de paquetes que te mantienen el sistema limpio.
Este articulo habla de sistemas gnu.
Aún así sí que es mejor tener copias de las mismas librerías (mismo en el nuevo Final Fantasy IX de Steam para PC, pasa eso) que tener librerías compartidas cuyo borrado accidental, bien por una aplicación o manualmente por no saber lo que hace puede llevar a que no funcionen decenas de estas mismas aplicaciones.
No, no lo es. Tu problema es que ni entiendes las ventajas reales de las librerias compartidas ni entiendes lo que es un gestor de paquetes.
Te quejas de que no optimizan y luego quieres empeorar las cosas porque no entiendes de lo que estás opinando.
Ya veo como se optimiza el código cuando .... la mayoría de las veces, por expertos.
¿Y que no funcione una aplicación es culpa de la librería compartida?
No, es culpa de que es mas importante sacarla antes que sacarla terminada.
Pero eso no significa que esté mal programada, significa que se ha sacado demasiado pronto y sin terminar. Eso no tiene nada que ver con los desarrolladores.
Ya te digo que en los 80 el código se optimizaba más respecto al hardware existente y se aprovechaba mejor.
Es lo que tenía el hardware muy limitado, que optimizabas o no funcionaba.
Ademas, el carecer de actualizaciones implicaba que o lo sacabas completamente probado o tendrías un problema, no así actualmente que lo que hacen es sacarlo sin terminar de probar y ya sacarán los parches luego.
Es lo que tiene el mercado, importa mas llegar el primero que ser mejor y de eso tenéis parte de culpa los usuarios.
#4#2 el inconveniente es convertirse parcialmente en windows. Espero que esto tenga un uso limitado, solo en aplicaciones comerciales que realmente necesiten sus propias bibliotecas
#2 Eso ya lo puedes hacer, solo molestate en hacer un paquete que incluya todas las librerías que necesite junto a el.
Por ejemplo el firefox, puedes bajarte el targz con el binario compilado de su página y hasta ahora me ha funcionado en Centos, Gentoo, Debian y Ubuntu que yo haya probado.
Gentoo por ejemplo tiene un paquete binario para firefox y lo que descarga e instala es el binario de mozilla(desde el mismo servidor de mozilla).
Ahora bien, la razón por la que no se hace es porque terminarías con copias repetidas de librerías en cada uno de los paquetes. QT son 250M, parece poco, pero imagina eso por cada aplicación que requiere Qt.
Yo no tengo kde completo en mi sistema, aún así tengo mas de cuarenta aplicaciones que tienen como dependencia Qt y eso supondría desperdiciar mas de 10GiB de espacio repitiendo los mismos datos una y otra vez(triplicaría el espacio que ocupa el sistema). Esto es solo teniendo en cuenta Qt, pero se repetiría con todas las otras librerías que requieran.
El problema no es que utilices un gestor de paquetes para mantener solo una copia de dicha librería, el problema es no se tenga en cuenta la posibilidad de tener instaladas varias versiones de la misma librería de forma concurrente(Gentoo lo hace en ciertos casos).
#10 Eso lo dices como si no hubiese aplicaciones de Linux, así como de Windows que necesitan una versión de archivo o librería específica. Y esto es por la sencillez de que no todas las librerías, en ningún S.O son retrocompatibles.
Otro tema las instalaciones y desinstalaciones. Uno de los problemas existentes en esto es que en aplicaciones con archivos compartidos o que están en las carpetas del sistema, cuando la aplicación se desinstala el S.O no sabe si esos archivos se pueden borrar o no. Por eso existe aplicaciones que meten, aún estando repetidos todos los archivos necesarios en la carpeta de dicha aplicación.
Por otro lado. Ni siquiera cuando se desinstala una aplicación, se borra por completo siempre, quedando restos que en ciertos casos pueden dar problemas. Además las aplicaciones que, hablando de problemas o errores las aplicaciones que no comparten archivos suelen dar muchos menos que las que si lo hacen y no sólo en sí en la propia aplicación sino en el propio S.O. Las aplicaciones que modifican o instalan archivos en las carpetas del sistema, pueden desestabilizar e incluso inutilizar este.
#14Eso lo dices como si no hubiese aplicaciones de Linux, así como de Windows que necesitan una versión de archivo o librería específica. Y esto es por la sencillez de que no todas las librerías, en ningún S.O son retrocompatibles.
Esta parte de tu respuesta significa que no has entendido lo que he dicho o no te has molestado en leer hasta el final antes de ir a responder corriendo.
En mi sistema ahora mismo el gestor de paquetes ha instalado estas dos versiones de x11-libs/wxGTK: 2.8.12.1-r1 y 3.0.2.0-r1
Ha instalado ambas por dependencias de otros paquetes que piden distintas versiones.
Por sencillez me evita mantener copias repetidas de librerías y ademas funciona perfectamente ahorrando desperdiciar espacio inútilmente.
Otro tema las instalaciones y desinstalaciones. ...... las carpetas del sistema, pueden desestabilizar e incluso inutilizar este.
Hey, te cuento un secreto... el Gestor de paquetes es tu amigo, utilizalo, que no hablamos de windows.
Si le cuentas que dependencias tiene tu paquete, el sabe cuando una librería deja de ser necesaria y la puede quitar cuando se elimina la última aplicación que depende de ella.
Eso evita que se pueda "desestabilizar" o "inutilizar" el sistema mientras se mantiene el sistema limpio sin librerías que no requiere.
Otra razón ademas para utilizar las librerías compartidas en lugar de individuales para cada uno es que solo se cargan una vez. Una vez están en memoria, el sistema reutiliza las páginas de código si otra aplicación necesita la misma librería ahorrando memoria y tiempo(porque ya las tiene cargadas). Así que si dos procesos cargan las mismas librerías, las páginas de código se comparten y cada uno tiene las propias de datos.
Tu respuesta me ha dado la impresión de que tienes unos conocimientos sobre sistemas GNU(y sistemas operativos en general) bastante limitados. No digo que sea así, pero es la típica queja de alguien que no entiende el funcionamiento de un gestor de paquetes ni el porque se utilizan librerías compartidas y por eso cree que la solución para sus problemas-WinDLL es que cada aplicación del sistema venga con TODAS las librerías en su propio directorio.
#15 y #16 Entendí perfectamente y sí es cierto mis conocimientos de Linux son bastante más limitados que los de Windows, pero por lo que veo fuísteis vosotros quienes no me entendísteis o no del todo.
Si la versión más reciente de una librería, un archivo digamos de apoyo,... tuviese retrocompatbilidad con todas las versiones anteriores no haría falta instalar más de una versión. Es más me parece una soberana estupidez mantener distintas versiones de un mismo archivo donde a lo mejor sólo cambian 10 líneas de código. Pero bueno viendo como se programa a veces, tampoco me extraña.
Además en ningún momento digo que esté en contra de las librerías compartidas y ya se para que se usan y como se usan, gracias.
#19Entendí perfectamente y sí es cierto mis conocimientos de Linux son bastante más limitados que los de Windows, pero por lo que veo fuísteis vosotros quienes no me entendísteis o no del todo.
Se te entendió perfectamente, y lo que dices es una soberana estupidez. Pero de verdad, a lo grande, no lo que tu crees que es repetir dos versiones de librerías distintas. Ahora te explico porque lo es y porque es cuanto menos curioso que pienses tan distinto entre una y otra situación.
Es más me parece una soberana estupidez mantener distintas versiones de un mismo archivo donde a lo mejor sólo cambian 10 líneas de código.
Llamas estupidez soberana a tener dos versiones distintas de una libreria porque no son compatibles.
¿Que crees que es el querer que se repitan librerías en todos los programas aunque sean exactamente la misma versión?
Ya no hablamos de repetir la librería dos veces, hablamos de repetirla decenas de veces.
Pero bueno viendo como se programa a veces, tampoco me extraña.
Para saber si el cambio tiene razón deberías mirar el código, entender porque se ha hecho y entonces podrías decidir si el no mantener la compatibilidad en la librería es bueno o malo.
En algo como el núcleo es un problema(aunque podría ser comprensible y necesário), porque solo puedes tener uno.
En algo como librerías... depende de que puedas tener varias versiones instaladas es una putada o no es relevante.
Además en ningún momento digo que esté en contra de las librerías compartidas y ya se para que se usan y como se usan, gracias.
Lo sabrás, pero no lo entiendes bien.
#21 Que si venga lo que digáis. Yo sigo manteniendo que es una estupidez mantener dos versiones de una misma librería, especialmente cuando una es una revisión o subversión de otra y apenas hay cambios. Y sino explícame porque es bueno tener dos versiones, pero explícame una razón lógica que ilógicas ya me se unas cuantas.
Y vuelvo a repetir tal como se programa sin optimizar el código y desaprovechando hardware, como se hace ahora (demasiadas veces), tampoco me extraña.
#23Yo sigo manteniendo que es una estupidez mantener dos versiones de una misma librería
Pero defiendes como mejor opción tener montones de copias de librerías repetidas en el sistema.
Tu razonamiento no es solo ilógico, ademas es incongruente.
especialmente cuando una es una revisión o subversión de otra y apenas hay cambios. Y sino explícame porque es bueno tener dos versiones, pero explícame una razón lógica que ilógicas ya me se unas cuantas.
Que sea una revisión o una subversión no significa que sea compatible si se ha cambiado algo. Todo depende de lo que se cambie.
Pueden tener cambios suficientes para que una aplicación hecha para la versión anterior de problemas con la nueva.
Y vuelvo a repetir tal como se programa sin optimizar el código y desaprovechando hardware, como se hace ahora (demasiadas veces), tampoco me extraña.
Puedes repetirlo todas las veces que quieras, no va a dejar de ser una falacia por tu parte. Una cosa no tiene nada que ver con la otra.
Precisamente eliminar simbolos y funciones crea incompatibilidades pero aprovecha mejor el hardware al eliminar cosas innecesarias pero que una aplicación espera encontrar al cargar esa librería porque se compiló para la versión que si lo tenía.
Cambiar una llamada del api, crea incompatibilidad entre versiones de la librería, pero puede que optimice el código.
#24 Primero en ningún momento hablo de tener varias copias de una misma librería en sí sino que hablaba que respecto a desinstalar un programa es mucho más fácil, que tener que andar revisando si una librería es compartida por otro programa. Y en cualquier caso eso debería ser cosa del programador de la aplicación y del propio S.O para que no borre algo que se necesite.
Aún así sí que es mejor tener copias de las mismas librerías (mismo en el nuevo Final Fantasy IX de Steam para PC, pasa eso) que tener librerías compartidas cuyo borrado accidental, bien por una aplicación o manualmente por no saber lo que hace puede llevar a que no funcionen decenas de estas mismas aplicaciones.
Por cierto esto:
Puedes repetirlo todas las veces que quieras, no va a dejar de ser una falacia por tu parte. Una cosa no tiene nada que ver con la otra.
Precisamente eliminar simbolos y funciones crea incompatibilidades pero aprovecha mejor el hardware al eliminar cosas innecesarias pero que una aplicación espera encontrar al cargar esa librería porque se compiló para la versión que si lo tenía.
Cambiar una llamada del api, crea incompatibilidad entre versiones de la librería, pero puede que optimice el código.
Ya veo como se optimiza el código cuando las aplicaciones funcionan cada vez peor, especialmente los videojuegos que muchos de ellos, necesitan parches la primera semana desde su salida al mercado. Lo que me demuestra que o bien en la fase Beta alguien se toca las narices o que no es lo suficientemente larga esta. Porque además no hablamos de pequeños fallos sino de fallos abismales que hagan que no funcione un aplicación, juego o de problemas graves. Y eso que se suponen programadas, la mayoría de las veces, por expertos.
Ya te digo que en los 80 el código se optimizaba más respecto al hardware existente y se aprovechaba mejor.
el concepto es interesante y práctico, pero seria de alguna manera acabar teniendo archivos repetidos, con lo cual inflaria el tamaño en disco ocupado por las aplicaciones. un sistema comprimido como squashfs estaria muy bien para esto, algunas distros como tinycore funcionan así. me he fijado también que muchas .apk de android vienen con librerias para x86, vamos que te estás bajando más datos innecesariamente si lo que tienes es un soc ARM.. vamos, que estas soluciones todo en uno estan muy bien pero también tiene sus inconvenientes.
#4 Pues si uno de los inconvenientes sería convertir aplicaciones que funcionan en fatware https://es.wikipedia.org/wiki/Software_inflado. Cada aplicación cargando sus propias dependencias, aunque sean las mismas que las de otras aplicaciones que estén en ejecución, por lo que ya estaríamos desperdiciando memoria ademas de disco. Bueno a menos que optimicen la opción que vi en un kernel 3.x (no me acuerdo de la versión exacta) donde se detectarían bloques de memoria con contenido idéntico y se optimizaría su uso haciendo que en lugar de lanzar nuevamente esas aplicaciones se utilicen punteros apuntando a esos bloques.
Esta opción todavía no la he visto en uso, yo en su tiempo la vi muy útil para sistemas paravirtualizados.
Comentarios
Brujería!
sino instalando un paquete que integre todas o casi todas sus dependencias y sea utilizable en cualquier distribución sin recompilar.
Se llama compilación estática.
De nada.
#3 Anda anda, seguro que tu eres de esos que dicen que el running es hacer jogging que antes era sencillamente correr...
#3 Bueno pero aquí añaden seguridad (checksums, firmas), posibilidad de tienda de aplicaciones, , estándar de árbol de directorios, múltiples versiones y cambiar entre ellas más fácilmente.
#13 Cuando dices «aquí añaden» olvidaste poner el "no" en medio. Eso o no tienes muy claro lo que dices.
Bueno pero aquí añaden seguridad (checksums, firmas),
Cosa que ya puedes hacer con los ejecutables por lo que no añades nada.
posibilidad de tienda de aplicaciones
También tienes, así que sigues sin añadir nada.
estándar de árbol de directorios
Ese que ya existe.
múltiples versiones
Siempre se ha podido.
cambiar entre ellas más fácilmente.
No necesito cambiar entre ellas, están todas las versiones siempre disponibles.
En resumen, que todo lo que dices que añade es falso, siempre se ha podido o hace muchísimo que se puede hacer.
#17
No has entendido nada.
#18 Entonces deberías explicarte mejor.
Si no has dicho lo que has dicho, es que tu forma de expresarte ha sido equivocada.
Has dicho que añade cosas que realmente ya están.
Tiene sentido para algunos paquetes... pero la mayoría del sistema debe estar basado en repositorios de toda la vida, por seguridad, por rendimiento, etc.
Vaya, solo le falta decir que el paquete venga en disquetes y habremos reinventado la rueda.
Mac OS X funciona a base de esto y binarios gordos (fat binaries) cuando hicieron la transición de PowerPC a IA32.
Por otra parte... GNU Guix lleva la delantera a todo esto con código fuente compilable y reproducible.
#12 El concepto de reproducible builds lo adoptaron en F-droid. El famoso repositorio de software libre para Android.
https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds
#25 Primero en ningún momento hablo de tener varias copias de una misma librería en sí
Si lo haces.
sino que hablaba que respecto a desinstalar un programa es mucho más fácil, que tener que andar revisando si una librería es compartida por otro programa. Y en cualquier caso eso debería ser cosa del programador de la aplicación y del propio S.O para que no borre algo que se necesite.
Ese es tu problema si utilizas windows, aprende a usar gestores de paquetes que te mantienen el sistema limpio.
Este articulo habla de sistemas gnu.
Aún así sí que es mejor tener copias de las mismas librerías (mismo en el nuevo Final Fantasy IX de Steam para PC, pasa eso) que tener librerías compartidas cuyo borrado accidental, bien por una aplicación o manualmente por no saber lo que hace puede llevar a que no funcionen decenas de estas mismas aplicaciones.
No, no lo es. Tu problema es que ni entiendes las ventajas reales de las librerias compartidas ni entiendes lo que es un gestor de paquetes.
Te quejas de que no optimizan y luego quieres empeorar las cosas porque no entiendes de lo que estás opinando.
Ya veo como se optimiza el código cuando .... la mayoría de las veces, por expertos.
¿Y que no funcione una aplicación es culpa de la librería compartida?
No, es culpa de que es mas importante sacarla antes que sacarla terminada.
Pero eso no significa que esté mal programada, significa que se ha sacado demasiado pronto y sin terminar. Eso no tiene nada que ver con los desarrolladores.
Ya te digo que en los 80 el código se optimizaba más respecto al hardware existente y se aprovechaba mejor.
Es lo que tenía el hardware muy limitado, que optimizabas o no funcionaba.
Ademas, el carecer de actualizaciones implicaba que o lo sacabas completamente probado o tendrías un problema, no así actualmente que lo que hacen es sacarlo sin terminar de probar y ya sacarán los parches luego.
Es lo que tiene el mercado, importa mas llegar el primero que ser mejor y de eso tenéis parte de culpa los usuarios.
sino instalando un paquete que integre todas o casi todas sus dependencias y sea utilizable en cualquier distribución sin recompilar.
Ojalá.
Salu2
#4 #2 el inconveniente es convertirse parcialmente en windows. Espero que esto tenga un uso limitado, solo en aplicaciones comerciales que realmente necesiten sus propias bibliotecas
#2 Eso ya lo puedes hacer, solo molestate en hacer un paquete que incluya todas las librerías que necesite junto a el.
Por ejemplo el firefox, puedes bajarte el targz con el binario compilado de su página y hasta ahora me ha funcionado en Centos, Gentoo, Debian y Ubuntu que yo haya probado.
Gentoo por ejemplo tiene un paquete binario para firefox y lo que descarga e instala es el binario de mozilla(desde el mismo servidor de mozilla).
Ahora bien, la razón por la que no se hace es porque terminarías con copias repetidas de librerías en cada uno de los paquetes. QT son 250M, parece poco, pero imagina eso por cada aplicación que requiere Qt.
Yo no tengo kde completo en mi sistema, aún así tengo mas de cuarenta aplicaciones que tienen como dependencia Qt y eso supondría desperdiciar mas de 10GiB de espacio repitiendo los mismos datos una y otra vez(triplicaría el espacio que ocupa el sistema). Esto es solo teniendo en cuenta Qt, pero se repetiría con todas las otras librerías que requieran.
El problema no es que utilices un gestor de paquetes para mantener solo una copia de dicha librería, el problema es no se tenga en cuenta la posibilidad de tener instaladas varias versiones de la misma librería de forma concurrente(Gentoo lo hace en ciertos casos).
#10 Eso lo dices como si no hubiese aplicaciones de Linux, así como de Windows que necesitan una versión de archivo o librería específica. Y esto es por la sencillez de que no todas las librerías, en ningún S.O son retrocompatibles.
Otro tema las instalaciones y desinstalaciones. Uno de los problemas existentes en esto es que en aplicaciones con archivos compartidos o que están en las carpetas del sistema, cuando la aplicación se desinstala el S.O no sabe si esos archivos se pueden borrar o no. Por eso existe aplicaciones que meten, aún estando repetidos todos los archivos necesarios en la carpeta de dicha aplicación.
Por otro lado. Ni siquiera cuando se desinstala una aplicación, se borra por completo siempre, quedando restos que en ciertos casos pueden dar problemas. Además las aplicaciones que, hablando de problemas o errores las aplicaciones que no comparten archivos suelen dar muchos menos que las que si lo hacen y no sólo en sí en la propia aplicación sino en el propio S.O. Las aplicaciones que modifican o instalan archivos en las carpetas del sistema, pueden desestabilizar e incluso inutilizar este.
Salu2
#14 Eso lo dices como si no hubiese aplicaciones de Linux, así como de Windows que necesitan una versión de archivo o librería específica. Y esto es por la sencillez de que no todas las librerías, en ningún S.O son retrocompatibles.
Esta parte de tu respuesta significa que no has entendido lo que he dicho o no te has molestado en leer hasta el final antes de ir a responder corriendo.
En mi sistema ahora mismo el gestor de paquetes ha instalado estas dos versiones de x11-libs/wxGTK: 2.8.12.1-r1 y 3.0.2.0-r1
Ha instalado ambas por dependencias de otros paquetes que piden distintas versiones.
Por sencillez me evita mantener copias repetidas de librerías y ademas funciona perfectamente ahorrando desperdiciar espacio inútilmente.
Otro tema las instalaciones y desinstalaciones. ...... las carpetas del sistema, pueden desestabilizar e incluso inutilizar este.
Hey, te cuento un secreto... el Gestor de paquetes es tu amigo, utilizalo, que no hablamos de windows.
Si le cuentas que dependencias tiene tu paquete, el sabe cuando una librería deja de ser necesaria y la puede quitar cuando se elimina la última aplicación que depende de ella.
Eso evita que se pueda "desestabilizar" o "inutilizar" el sistema mientras se mantiene el sistema limpio sin librerías que no requiere.
Otra razón ademas para utilizar las librerías compartidas en lugar de individuales para cada uno es que solo se cargan una vez. Una vez están en memoria, el sistema reutiliza las páginas de código si otra aplicación necesita la misma librería ahorrando memoria y tiempo(porque ya las tiene cargadas). Así que si dos procesos cargan las mismas librerías, las páginas de código se comparten y cada uno tiene las propias de datos.
Tu respuesta me ha dado la impresión de que tienes unos conocimientos sobre sistemas GNU(y sistemas operativos en general) bastante limitados. No digo que sea así, pero es la típica queja de alguien que no entiende el funcionamiento de un gestor de paquetes ni el porque se utilizan librerías compartidas y por eso cree que la solución para sus problemas-WinDLL es que cada aplicación del sistema venga con TODAS las librerías en su propio directorio.
#15 y #16 Entendí perfectamente y sí es cierto mis conocimientos de Linux son bastante más limitados que los de Windows, pero por lo que veo fuísteis vosotros quienes no me entendísteis o no del todo.
Si la versión más reciente de una librería, un archivo digamos de apoyo,... tuviese retrocompatbilidad con todas las versiones anteriores no haría falta instalar más de una versión. Es más me parece una soberana estupidez mantener distintas versiones de un mismo archivo donde a lo mejor sólo cambian 10 líneas de código. Pero bueno viendo como se programa a veces, tampoco me extraña.
Además en ningún momento digo que esté en contra de las librerías compartidas y ya se para que se usan y como se usan, gracias.
Salu2
#19 Entendí perfectamente y sí es cierto mis conocimientos de Linux son bastante más limitados que los de Windows, pero por lo que veo fuísteis vosotros quienes no me entendísteis o no del todo.
Se te entendió perfectamente, y lo que dices es una soberana estupidez. Pero de verdad, a lo grande, no lo que tu crees que es repetir dos versiones de librerías distintas. Ahora te explico porque lo es y porque es cuanto menos curioso que pienses tan distinto entre una y otra situación.
Es más me parece una soberana estupidez mantener distintas versiones de un mismo archivo donde a lo mejor sólo cambian 10 líneas de código.
Llamas estupidez soberana a tener dos versiones distintas de una libreria porque no son compatibles.
¿Que crees que es el querer que se repitan librerías en todos los programas aunque sean exactamente la misma versión?
Ya no hablamos de repetir la librería dos veces, hablamos de repetirla decenas de veces.
Pero bueno viendo como se programa a veces, tampoco me extraña.
Para saber si el cambio tiene razón deberías mirar el código, entender porque se ha hecho y entonces podrías decidir si el no mantener la compatibilidad en la librería es bueno o malo.
En algo como el núcleo es un problema(aunque podría ser comprensible y necesário), porque solo puedes tener uno.
En algo como librerías... depende de que puedas tener varias versiones instaladas es una putada o no es relevante.
Además en ningún momento digo que esté en contra de las librerías compartidas y ya se para que se usan y como se usan, gracias.
Lo sabrás, pero no lo entiendes bien.
#21 Que si venga lo que digáis. Yo sigo manteniendo que es una estupidez mantener dos versiones de una misma librería, especialmente cuando una es una revisión o subversión de otra y apenas hay cambios. Y sino explícame porque es bueno tener dos versiones, pero explícame una razón lógica que ilógicas ya me se unas cuantas.
Y vuelvo a repetir tal como se programa sin optimizar el código y desaprovechando hardware, como se hace ahora (demasiadas veces), tampoco me extraña.
Salu2
#23 Yo sigo manteniendo que es una estupidez mantener dos versiones de una misma librería
Pero defiendes como mejor opción tener montones de copias de librerías repetidas en el sistema.
Tu razonamiento no es solo ilógico, ademas es incongruente.
especialmente cuando una es una revisión o subversión de otra y apenas hay cambios. Y sino explícame porque es bueno tener dos versiones, pero explícame una razón lógica que ilógicas ya me se unas cuantas.
Que sea una revisión o una subversión no significa que sea compatible si se ha cambiado algo. Todo depende de lo que se cambie.
Pueden tener cambios suficientes para que una aplicación hecha para la versión anterior de problemas con la nueva.
Y vuelvo a repetir tal como se programa sin optimizar el código y desaprovechando hardware, como se hace ahora (demasiadas veces), tampoco me extraña.
Puedes repetirlo todas las veces que quieras, no va a dejar de ser una falacia por tu parte. Una cosa no tiene nada que ver con la otra.
Precisamente eliminar simbolos y funciones crea incompatibilidades pero aprovecha mejor el hardware al eliminar cosas innecesarias pero que una aplicación espera encontrar al cargar esa librería porque se compiló para la versión que si lo tenía.
Cambiar una llamada del api, crea incompatibilidad entre versiones de la librería, pero puede que optimice el código.
#24 Primero en ningún momento hablo de tener varias copias de una misma librería en sí sino que hablaba que respecto a desinstalar un programa es mucho más fácil, que tener que andar revisando si una librería es compartida por otro programa. Y en cualquier caso eso debería ser cosa del programador de la aplicación y del propio S.O para que no borre algo que se necesite.
Aún así sí que es mejor tener copias de las mismas librerías (mismo en el nuevo Final Fantasy IX de Steam para PC, pasa eso) que tener librerías compartidas cuyo borrado accidental, bien por una aplicación o manualmente por no saber lo que hace puede llevar a que no funcionen decenas de estas mismas aplicaciones.
Por cierto esto:
Puedes repetirlo todas las veces que quieras, no va a dejar de ser una falacia por tu parte. Una cosa no tiene nada que ver con la otra.
Precisamente eliminar simbolos y funciones crea incompatibilidades pero aprovecha mejor el hardware al eliminar cosas innecesarias pero que una aplicación espera encontrar al cargar esa librería porque se compiló para la versión que si lo tenía.
Cambiar una llamada del api, crea incompatibilidad entre versiones de la librería, pero puede que optimice el código.
Ya veo como se optimiza el código cuando las aplicaciones funcionan cada vez peor, especialmente los videojuegos que muchos de ellos, necesitan parches la primera semana desde su salida al mercado. Lo que me demuestra que o bien en la fase Beta alguien se toca las narices o que no es lo suficientemente larga esta. Porque además no hablamos de pequeños fallos sino de fallos abismales que hagan que no funcione un aplicación, juego o de problemas graves. Y eso que se suponen programadas, la mayoría de las veces, por expertos.
Ya te digo que en los 80 el código se optimizaba más respecto al hardware existente y se aprovechaba mejor.
Salu2
#14 Me parece que no entendiste lo que dijo #10.
No esta hablando de la mugre que hace Windows
el concepto es interesante y práctico, pero seria de alguna manera acabar teniendo archivos repetidos, con lo cual inflaria el tamaño en disco ocupado por las aplicaciones. un sistema comprimido como squashfs estaria muy bien para esto, algunas distros como tinycore funcionan así. me he fijado también que muchas .apk de android vienen con librerias para x86, vamos que te estás bajando más datos innecesariamente si lo que tienes es un soc ARM.. vamos, que estas soluciones todo en uno estan muy bien pero también tiene sus inconvenientes.
#4 Pues si uno de los inconvenientes sería convertir aplicaciones que funcionan en fatware https://es.wikipedia.org/wiki/Software_inflado. Cada aplicación cargando sus propias dependencias, aunque sean las mismas que las de otras aplicaciones que estén en ejecución, por lo que ya estaríamos desperdiciando memoria ademas de disco. Bueno a menos que optimicen la opción que vi en un kernel 3.x (no me acuerdo de la versión exacta) donde se detectarían bloques de memoria con contenido idéntico y se optimizaría su uso haciendo que en lugar de lanzar nuevamente esas aplicaciones se utilicen punteros apuntando a esos bloques.
Esta opción todavía no la he visto en uso, yo en su tiempo la vi muy útil para sistemas paravirtualizados.
A lo mejor si consiguen hacer esto resulta que por fin es el año de Linux en el escritorio.