Hola:
Siempre cabe la posibilidad , ya veremos como lo van resolviendo.
Quiero pensar que lo que harán será ir subiendo a slowroll las snapshots “patanegra” de Tumbleweed.
Algo parecido --guardando las distancias-- a lo que hace Mozilla con Firefox y Firefox-esr
Pero como he dicho antes , para esto está este período , ir viendo como desarrolla , como lo van moviendo etc.
Saludos.
1 Like
Hola.
En general, no, pero no deja de ser un producto experimental precisamente por ese tipo de cosas. Pero Leap siempre ha funcionado así de todas formas.
No creo.
Salud!!
1 Like
Hola:
En principio tienes razón , si hacemos caso al gráfico puesto por el equipo:
Slowroll nunca llega a ser igual a la snapshot de tumbleweed , habrá que ver una vez slowroll esté en produción normal y estable que diferencias habrá con tumbleweed en los momentos que se acerquen más.
Sea como fuese o fuere , interesante movimiento de openSUSE.
Saludos.
Hola:
Viernes de actualización.
Todo en orden.
¡Qué aburrimiento! 
Ilustremos:
No hay cambio de versión.
Ya existe diferencia con Tumbleweed , por ejemplo en la versión de Plasma , 5.27.8 vs 5.27.9
Saludos.
1 Like
Yo estoy hace tiempo con MicroOS en x64 (GNOME), Tumbleweed (KDE), MicroOS en un Pi4(ARM64) y también en una tablilla vieja de 32 bits corriendo Tumbleweed JEOS arm7l y todos funciona de maravilla.
Pero ya me enfoco mas hacia MicroOS porque es el futuro. Saludos!
2 Likes
Bienvenido @kwag al foro.
Gracias por contadnos lo que usas del gecko. Preséntate en este hilo y nos cuentas mas cosas de ti:
Have a lot of fun!
Por lo que veo en tus capturas, las renovaciones (“upgrades”) hay que hacerlas como en Tumbleweed 
Pensaba que en esta se iba a implementar una aplicación para hacerlo, de forma que facilitase el proceso.
1 Like
Hola:
Si, de momento se hacen como en TW , no sé si piensan cambiar eso.
De hecho, siguen actualizando paquetes de versión sin cambiar de snapshot.
Quiero pensar que aun se está --la están-- acomodando .
Seguimos expectantes , pero si , espero algo más.
Porque sino será como tener TW y solo cambiar la frecuencia de actualización y para eso no hace falta una “nueva” versión , con una modificación de Packagekit es suficiente.
Saludos.
Hola.
En principio, la diferencia, como he tratado de explicar más arriba, no es simplemente “el número de actualizaciones”, sino a qué versiones exactas de cada paquete corresponden.
Otra cosa diferente es si la idea funciona de forma apropiada. Esto es:
- tumbleweed: cada vez que hay paquetes nuevos, se genera una instantánea nueva.
- slowroll: una vez al mes se genera una instantánea nueva.
Con lo que la teoría es muy sencilla, pero otra cosa es qué pasa exactamente con las instantáneas, si se generan apropiadamente, al ritmo adecuado, etc. Probablemente sea cuestión de prueba y error.
Y por supuesto, siempre nos ha faltado un mecanismo razonable de actualización. Y eso que con cockpit puedes manejarlas, pero no deja de ser un servicio http.
(Ejemplo de un Tumblweed)
Lo guay sería que packagekit, tanto en Tumbleweed como en Slowroll, pudiera manejar actualizaciones (upgrades). Pero el duro y largo camino que ha recorrido Packagekit hasta llegar aquí no me inspira gran confianza.
También es posible programar las actualizaciones automáticas, pero no sé cómo podría manejarse el aspecto gráfico: preguntar si realizarla, avisar si hay que reiniciar… cosas que sí maneja Packagekit…
[[edito]]
No acabo de encontrar información fiable de si Packagekit maneja correctamente las actualizaciones de Tumbleweed. Aquí dicen que sí.
Packagekit por su parte admite actualización diaria, semanal y mensual.
Salud!!
1 Like
De hecho, yo uso el plasmoide “Actualizaciones de software” (paquete plasma5-pk-updates) que si no me equivoco es Packagekit (tiene las opciones diaria, semanal y mensual) y no tengo ningún tipo de problemas en TW.
Sólo en 1 ocasión teclee el zypper dup. Lo habitual es usar el plasmoide. El Centro de información se va actualizando correctamente con el número de snapshot. La última que actualicé fue a la 20231028 (estoy a la espera del kernel 6.6).
Saludos
Saludos
Estoy de acuerdo con tu último párrafo. De hecho, si implementaran una forma sencilla sin CLI de actualizar, sería la distro ideal “para siempre” que instalaría a todos aquellos usuarios que ni tienen ni necesitan tener conocimientos de la terminal de comandos y sin embargo, siempre tendrían la última versión de la distribución.
Hola.
Bueno, según lo dicho eso sería PackageKit con el plasmoide/widget de actualización.
Entonces el problema (menor) sería manejar las actualizaciones en Discover (Descubrir), porque esta aplicación puede manejar actualizaciones en el espacio de usuario pero necesita clave de root cada vez que tiene que actualizar en el espacio de sistema.
En cambio, en Aeon/Kalpa las actualizaciones de sistema tienen que ser transaccionales por definición y se hacen automáticamente, mientras que packagekit/Discover sólo se encargan de las actualizaciones en espacio de usuario principalmente a través de flatpaks (está por ver cómo instalar plugins y demás), y también se pueden automatizar. Eso sí, ¿cómo revertir aquí?
Salud!!
Pero es que PackageKit no entra en esos detalles. Estoy totalmente de acuerdo con los desarrolladores de PackageKit, que afirman que el usuario no tiene ni por qué saber qué es un paquete. En todo caso, sería openSUSE el que estableciera unos parámetros por defecto para la resolución de conflictos, que el usuario podría habiilitar o deshabilitar según sus conocimientos.
A estas alturas, es incompresible que openSUSE siga obligando a tirar de línea de comandos cuando hay conflictos simples de paquetes, como los típicos de Tumbleweed (pero que también se dan ocasionalmente en LEAP):
Existe un paquete más reciente. Seleccione una opción:
1. Instalar el nuevo paquete
2. Mantener el paquete instalado
Algo que podría resolverse con GUI, igual que hace cuando se renueva de la versión actualmente instalada a una superior o se reinstala sobre la versión previa. Sin embargo, openSUSE deja al usuario que lo tenga que resolver a través de la linea de comandos. No sé si es una estrategia de SUSE a nivel de empresa, para que hasta algo tan simple sean los administradores los que tengan que hacerlo, la verdad. Luego se extrañan que distros que para mí son inferiores como Linux Mint hasta MX Linux, sean más populares. Normal que sean más populares no ven una línea de comandos nunca para cosas tan sencillas como las actualizaciones.
Yo tengo muy claro que no voy a usar Flatpak. Antes prefiero usar Distrobox y usar una versión compilada para otro sistema. Pero eso es otra discusión.
Hola.
En Leap es fácil, tienes YaST, o más bien, YOU: YaST online update, que es lo que usaba cuando packagekit no resolvía correctamente las dependencias.
Por su parte, Packagekit parece funcionar adecuadamente. Si realmente hace un zypper dup aunque sea con su propia configuración por defecto, entonces no es necesario mucho más. Puedes deseleccionarlos paquetes que no quieras actualizar.
El problema no es la actualización. El problema realmente tiene dos partes:
- cómo resolver cuando una actualización falla.
- cómo resolver cuando una actualización requiere reinicio.
Packagekit resuelve bien la segunda parte, presentando un aviso en el sistema de notificaciones. En cuanto a la primera, puede requerir intervención manual o incluso el uso de Snapper.
Es que en una empresa lo tienen que hacer los administradores sí o sí. El rollo es instalar TW a un pariente en su portátil y soltarlo en el mundo!! 
Hace que no pruebo sus versiones, pero que yo haya visto hace lo mismo que packagekit y no me extrañaría si usase packagekit.
El asunto es que si packagekit soporta zypper dup, ya está, ya tienes todo lo necesario.
Salud!!
Yo creo que sí, al post de más arriba me remito. En lugar del dup uso el plasmoide (eso de widget es del lado oscuro, ¡blasfemo! 
) y funciona perfectamente.
Eso no quita que tienes razón con lo de los conflictos de paquetes al instalar. En mi caso no puede pasar porque lo que instalo de Packman tiene prioridad 70, por encima de la prioridad del Sistema (que es 98). Otra cosa son las dependencias, que hay que hacerlo manual.
Saludos
1 Like
Yo llevo usando hace años ese plasmoide, que yo siempre activaba mediante “Yast Software, Configuración, Actualización en linea” y se instalaba automáticamente. Sin embargo, los problemas comentados, tanto en LEAP como sobre todo en TW, acababan apareciendo, sin poder resolver desde el interfaz los mismos, ya que en la mayoría de los casos, deshabilitar que se instale algo (deseleccionar paquetes que ha comentado karlggest) no resuelve el conflicto, lo postpone y, a la larga, lo agrava, porque no es que el usuario no quiera instalar esos paquetes, es que el plasmoide (no packagekit, que no tiene capacidad de interactuar con el usuario) no ofrece opciones al usuario para la resolución del conflicto.
Sin embargo, le voy a dar una oportunidad a discover-notifier , que se instala desde el propio Discover, y que desinstala el mencionado plasmoide para ser él el que gestione las actualizaciones. En cuanto lo haya probado lo suficiente, comentaré al respecto.
1 Like
Hola:
El problema no es la actualización. El problema realmente tiene dos partes:
cómo resolver cuando una actualización falla.
cómo resolver cuando una actualización requiere reinicio. </quote>
Me parece que suele anunciarlo, y en zypper también ; ademas, que crees que se ejecuta en letras de color azul , ademas del dracut final , para hacer algunos cambios, ademas del grub y de el initrd y initramfs , no le queda otra que ejecutar los script y si cambia los init, o el firmaware (efi) también debe reiniciar para que coja los cambios (vuelva a cargarlos , como cuando se hace dracut --force) .
Ademas , al iniciar purga los kernel ,
Y si es por una sanpshots, también merece la pena el reinicio.
Pakagekit , no se si lo hace en 2º plano, nunca me fije y si hay un problema, se demarca el que tiene conflicto y se actualiza lo demás, y si es temporal se actualiza el que falta y si no como a veces, desaparece de la actualización .
Saludos .
PD. me olvide contestar en el momento, disculpas .
Hola!
@mikrios , me refiero a que el problema general de cualquier sistema operativo tiene esas dos partes: qué hacer si falla, qué hacer cuando hay que reiniciar.
Por ejemplo, podrías crear un servicio con un temporizador para actualizar con zypper automáticamente. Al fin y al cabo es lo que hace Aeon o Kalpa, y todo MicroOS.
En las derivadas de MicroOS se toma la decisión de que toda actualización del sistema necesita reiniciar. Incluso se recuerda que si usas zypper ps puedes ver los procesos que habría que reiniciar en una actualización de Leap, por ejempo. Siguiendo con MicroOS, eso nos deja cómo determinar cuando es conveniente reiniciar. Podemos reiniciar inmediatamente, o programarlo para las 12:00, digamos, de forma que si reinicias antes ya cuenta como reinicio y ya está.
https://en.opensuse.org/Kubic:Update_and_Reboot#Reboot_Strategy_Options
El otro problema lo resuelven haciendo actualizaciones transaccionales y en caso de emergencia con transaccional-update rollbak
En Tumbleweed no usamos las actualizaciones transaccionales y no sé si queremos tanto automatismo. Pero aun así, si yo mañana le instalo un sistema a cualquiera, ¿cómo le digo que tiene que hacer para actualizar? Lo ideal sería que pulsando por ejemplo en el applet de packagekit (el plasmoide de actualización, por ejemplo) fuera suficiente. ¿Cómo resolver un error? probablemente esperando un par de días.
Yo uso Plasma, pero haiche gente rara por ahí
Salud!!
2 Likes
Hola:
Correcto.
Incluso meterse en el menú de edición .
Ademas forzar dracut, por lo que veo carga el sistema que está corriendo, en cambio creo que el que ejecuta el al final de la actualización, ya viene preparado para el que viene.
El plasmoid, observo que pone muchos de los problemas de seguridad , pero no me he fijado si lo hace, con zip (no se me a dado por mirar) .
Y todo es tal como comentas.
Saludos
Muy buenas … Una pregunta.
Uso leap 15.5 , en cajas he experimentado un poco con slowroll, pero no he notado gran diferencia con respecto a Tumbleweed.
¿Estoy en lo cierto ? O simplemente es una apreciación mia…
Saludos…