[Musix-usuarios] musix / ubuntu / kernels nuevos: necesitamos nuevas versiones de linux

[Marcos Guglielmetti]

El Martes, 30 de Septiembre de 2008 17:55, minombresbond escribió:
 | El día 29 de septiembre de 2008 13:32, Pablo Lozano
 |
 | <curchunflo1 en hotmail.com> escribió:
 | > Yo estoy en SID y anda bárbaro, sólo hay que tener ojo con la
 | > costumbre que tienen algunos de darle "apt-get upgrade" o
 | > "dist-upgrade" (safe-upgrade tengo yo) cada vez que se arranca
 | > la máquina, por lo general cuando aparece algo que da conflicto
 | > se resuelve en horas o en dos o tres días con otro apt-get
 | > upgrade. Y le exijo mucho a musix (además lo he achurado por
 | > todos lados): Tengo algunos fallos o demoras al arranque, pero
 | > creo que son culpa mía, y son dos:
 | >
 | > empieza a arrancar, carga todo hasta que llega a manager: nose
 | > que cosa, y dice ivman, ahí se queda hasta que le doy control+c 
 | > y sigue cargando perfectamente,
 | >
 | > el otro es que cada vez que arranco tengo que darle un
 | > dpkg-reconfigure hal dbus porque me da un "failed to initilize
 | > hal" todas las veces...
 |
 | a mi me llega a pasar eso y puede q me de un sincope o algo
 | parecido
 |
 | apt-get upgrade no es por ejemplo para pasar de estable a testing?


Podés usarlo para eso si querés, pero no necesariamente es para eso.

Es para actualizar los paquetes que estén disponibles para actualizar 
en la versión que sea que estés (o mejor dicho, a la versión a la que 
apunta tu sources.list, si apunta a testing, a testing, si a 
unstable, a unstable, si a stable, a stable)... sin eliminar nada 
para resolver dependencias.

Incluso se puede utilizar para desactualizar, del mismo modo pero al 
revés (si estás usando testing y deshabilitás ese repo en 
sources.list, y habilitás stable, haría un downgrade)

Si estás usando la rama Stable, entonces actualizará lo que encuentre 
actualizado allí (ejemplo: reparaciones de errores de seguridad), sin 
borrar nada.


Si estás usando la rama Testing, entonces actualizará lo que encuentre 
actualizado allí (ejemplo: reparaciones de errores de seguridad), sin 
borrar nada.

Si estás usando la rama Unstable, entonces actualizará lo que 
encuentre actualizado allí (ejemplo: reparaciones de errores de 
seguridad, nuevas versiones de los paquetes, que son más frecuentes 
que en testing, o sea, en testing cuando se está por congelar o se 
congelan los repositorios, las actualizaciones son casi como en 
stable), sin borrar nada.





 | por q alguien le daria en cada arranque? disculpen la ignorancia
 |
 | yo tengo testing, me limito a actualizar los paquetes desde
 | synaptic (q siempre son mas de 150), y en las aplicaciones que uso
 | todavia no me di cuenta q tiene de menos estable
 |

Testing o Unstable son menos estables _como repositorios_.

Es decir, los paquetes se mueven mucho en unstable, se renuevan mucho. 
En testing, según la época del ciclo, ahora deberían ser pocos los 
que se renuevan.

En estable, poquísimos.


Ahora, a la hora de hablar de estabilidad _de aplicaciones_ en sí, se 
supone -y en general es así- que las que están en debian stable son 
más estables que las del repositorio unstable, pero a veces sucede 
que las nuevas versiones que hay en unstable son más estables que las 
de los repositorios estables

el problema con unstable es la inestabilidad de los repositorios, y 
que en ellos pueden entrar aplicaciones con fallos críticos.

en testing no pueden ingresar con fallos críticos


en estable menos.


-- 
Marcos Guglielmetti - www.foros.musix.es | Soporte comunitario