Para una cosa realmente buena que tiene Linux, como es el sistema de paquetes, y a estos lumbreras no se les ocurre otra cosa que "windowsizarlo". Seguramente no han reparado en los dos principales inconvenientes de este sistema:
a) Cada paquete ocupará chorrocientos megas.
b) En vez de cargar una instancia de una libraría en memoria y compartirla, ahora cada programa tendrá su propia instancia. Resultado: la increíble memoria menguante.
Y ya puestos, me permito hacerles una sugerencia para mejorar aún más, si cabe, su "revolucionario" sistema de paquetes: compilen todos los programas estáticamente. Sí, claro, ocupan más, pero piensen en la comodidad de tener un sólo fichero binario en vez de tener todas esas estúpidas librerías molestando por en medio. ¡Y piensen en lo rápido que arrancarán los programas sin tener que realizar todos esos costosos enlaces dinámicos!
-
-- La belleza está en el interior (Jack el Destripador)
Cuidado con la parte b... después pasa como en Windows, que cada programa mete la librería que le apetece y crean incompatibilidad con otros programas... y pantallazo!!
Desde mi punto de vista, cada programa su librería, pero no completa, sino la parte extrictamente necesaria.
--
__________________________________________________
La sabiduría se halla en el buscar... Google power!!!
Inconveniente c: O se actualiza el programa cada vez que salga una nueva version de una libreria, o nos podemos reir con la cantidad de agujeros de seguridad que acumularemos.
Seguramente no han reparado en los dos principales inconvenientes de este sistema:
Seguramente sí. Y en la práctica no es el desastre apocalíptico que dices. Se gasta un poco más de disco y un poco más de memoria y se ganan otras cosas. Y lo mismo te digo del enlace estático: en muchos casos es mucho mejor sistema.
En vez de cargar una instancia de una libraría en memoria y compartirla, ahora cada programa tendrá su propia instancia. Resultado: la increíble memoria menguante.
En cualquier SO operativo multitarea moderno, cuando se ejecuta un programa, se reserva un cierto espacio dinámico de memoria para el proceso principal y sus bibliotecas asociadas. Este espacio de memoria es independiente del resto, por lo no se comparte la memoria de las bibliotecas ni siquiera si ejecutas el mismo programa varias veces. Esto es debido a una simple cuestión de estabilidad y seguridad.
Ya que mencionaron Windows 3.1 más arriba, en este pseudo-SO de multitarea cooperante sí se compartía la memoria de biliotecas, y era uno de las razones por las que era un sistema tan inestable. Supongamos que una DLL era usada por X, Y y Z. Si la DLL tenía un error y cascaba X llamaba cierta función, tanto Y como Z caían también. Por no hablar de los problemas de sincronización, etc. que se dan en este escenario.
Lo revolucionario sería poder incluir varios .deb/.rpm en uno. Así, se podría distribuir ej: un programa, que dentro de si mismo tenga el .deb de las gtk, o de lo que sea, y que esos .deb se instalen si no están disponibles a través de apt.
Tendría todas las ventajas del "método windows" y todas las de los sistemas linux. Es más, es posible que en caso de conflicto se recurriera a la solución pc-bsd - descomprimir las librerias preincluidas en el .deb en un solo subdirectorio en vez de en el sistema
Sssstupendo
(Puntos:5, Interesante)a) Cada paquete ocupará chorrocientos megas.
b) En vez de cargar una instancia de una libraría en memoria y compartirla, ahora cada programa tendrá su propia instancia. Resultado: la increíble memoria menguante.
Y ya puestos, me permito hacerles una sugerencia para mejorar aún más, si cabe, su "revolucionario" sistema de paquetes: compilen todos los programas estáticamente. Sí, claro, ocupan más, pero piensen en la comodidad de tener un sólo fichero binario en vez de tener todas esas estúpidas librerías molestando por en medio. ¡Y piensen en lo rápido que arrancarán los programas sin tener que realizar todos esos costosos enlaces dinámicos!
-
La belleza está en el interior (Jack el Destripador)
Re:Sssstupendo
(Puntos:1)( http://ww.google.es/ | Última bitácora: Martes, 01 Mayo de 2007, 16:43h )
Desde mi punto de vista, cada programa su librería, pero no completa, sino la parte extrictamente necesaria.
__________________________________________________
La sabiduría se halla en el buscar... Google power!!!
Re:Sssstupendo
(Puntos:2)( http://barrapunto.com/ | Última bitácora: Miércoles, 06 Julio de 2005, 21:28h )
...
Re:Sssstupendo
(Puntos:1)( http://barrapunto.com/ | Última bitácora: Lunes, 26 Mayo de 2014, 13:48h )
Seguramente sí. Y en la práctica no es el desastre apocalíptico que dices. Se gasta un poco más de disco y un poco más de memoria y se ganan otras cosas. Y lo mismo te digo del enlace estático: en muchos casos es mucho mejor sistema.
no es así
(Puntos:2)( http://barrapunto.com/ | Última bitácora: Domingo, 22 Mayo de 2005, 06:18h )
En cualquier SO operativo multitarea moderno, cuando se ejecuta un programa, se reserva un cierto espacio dinámico de memoria para el proceso principal y sus bibliotecas asociadas. Este espacio de memoria es independiente del resto, por lo no se comparte la memoria de las bibliotecas ni siquiera si ejecutas el mismo programa varias veces. Esto es debido a una simple cuestión de estabilidad y seguridad.
Ya que mencionaron Windows 3.1 más arriba, en este pseudo-SO de multitarea cooperante sí se compartía la memoria de biliotecas, y era uno de las razones por las que era un sistema tan inestable. Supongamos que una DLL era usada por X, Y y Z. Si la DLL tenía un error y cascaba X llamaba cierta función, tanto Y como Z caían también. Por no hablar de los problemas de sincronización, etc. que se dan en este escenario.
Re:Sssstupendo
(Puntos:2)muy de acuerdo
(Puntos:2)( http://www.terra.es/personal/diegocg )
Lo revolucionario sería poder incluir varios .deb/.rpm en uno. Así, se podría distribuir ej: un programa, que dentro de si mismo tenga el .deb de las gtk, o de lo que sea, y que esos .deb se instalen si no están disponibles a través de apt.
Tendría todas las ventajas del "método windows" y todas las de los sistemas linux. Es más, es posible que en caso de conflicto se recurriera a la solución pc-bsd - descomprimir las librerias preincluidas en el .deb en un solo subdirectorio en vez de en el sistema