Wenas Ñ=
On Tue, Jul 21, 2020 at 1:05 PM Alberto Planas Dominguez
On Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
wrote: [...] No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. YUM incluye rollbacks independientemente del sistema de ficheros. En el caso de Zypper, si quieres rollbacks, TIENES que usar btrfs o LVM ... No hay elección.
Perdon por entrar en la discusion.
Todo lo contrario ! Se agradecen opiniones de todo el mundo, faltaría más ! MHO: no es una "discusión".
Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no?
No, los descarga de las repos.
La idea de snapper + btrfs es que no se necesita tener una base de datos de rpms antiguos (local o en repositorio), y ademas queda generalizado para binarios y para ficheros de configuracion. Puedes recuperar el estado completo de un sistema, no solo la version de un paquete.
Totalmente de acuerdo. Yo lo he simplificado para mi caso en concreto: un paquete falla y hace que mi equipo no se pueda usar. Te puedo contar los tickets que tenemos de: "No sé qué ha pasado, pero me ha desaparecido el directorio $HOME/superimportante. Pero yo no he borrado nada." Gracias a los snapshots que ofrecen NetApp y ZFS se les recuperan los datos y todos contentos. Hoy en día (AFAIK), no se recomienda usar btrfs con el equivalente a Z1, Z2, y Z3 de ZFS (o RAID 5 ó 6). Por eso usamos NetApp y/o ZFS. Y sí, conozco otros sistemas operativos que hacen algo similar a lo que propone SUSE: FreeNAS/TrueNAS. Y no, zypper no es la única herramienta de gestión de paquetes que no soporta rollbacks.
Es este ultimo punto, tener una ya solucion generalizada external al gestor de paquetes, es lo que dificulta el argumento de implementar otra solucion que tecnicamente seria inferior.
MHO es que no es "inferior": tuve un problema concreto y me hubiera venido muy bien poder hacer un rollback. En este caso fue en un portátil. Hace unos meses fue en un clúster de cómputo en el que un yum update actualizó Python y los científicos no podían ejecutar sus trabajos. Hice un rollback y pudieron continuar. OJO! No digo que yum sea mejor, sólo expongo una situación que he vivido. Tampoco digo que no me guste zypper ni SUSE. Que no haya malentendidos.
En el caso de YUM (AFAIK), es una entrada en la BBDD de paquetes (de YUM, no en la de RPM) ... no han hecho nada "extraordinario/fuera de este mundo". AFAIK.
Implementar una bd de versiones paquetes en zypper podria tener sentido. Tener algo como "zypper history" seria util.
Exacto, es lo que digo: sería útil.
Ojo ! Esto es sólo una idea. Zypper es "propiedad" de SUSE y tiene todo el derecho del Mundo a no implementar el rollback en/dentro de zypper.
https://github.com/openSUSE/zypper (GPLv2)
Se pueden enviar PR.
Ya, y sé que hay gente que lo ha comentado/pedido/solicitado (no me acuerdo si en foros, listas de correo, ...). Como decía Carlos en un correo anterior, él también lo ha visto, pero no se acuerda dónde.
Sigo pensando que no debe ser una tarea hercúlea desarrollarlo y sería una opción bastante útil si, por ejemplo, estás con un sistema IoT y no tienes los 50 GB necesarios/recomendados para montar btrfs o LVM ... pero necesitas rollback porque el equipo/servidor está en un sitio remoto con difícil acceso físico: típico en entornos de laboratorio, I+D, ... en los que hay equipos en medio de la "nada".
Uhm MicroOS funciona con btrfs en sistemas ARM. Se hace rollback automatico en cuanto se encuentra algun problema.
Cierto, I stand corrected. Como decía en un correo anterior: agradezco este tipo de información porque no sé si las cosas han cambiado o no (hace un tiempo que no miro btrfs en detalle). Lo mismo digo con el tema de RAID 5 ó 6 (Z1, Z2 y Z3 de ZFS), ya que trabajas para SUSE: ¿considera SUSE que el equivalente a RAID 5 y 6 de btrfs está listo para producción? ¿Tiene clientes usándolo? ¿En qué entornos lo están usando los clientes? ...
Vuelvo a lo de antes, FLOSS: la F viene de Free as in Free Speech ... IOW: libertad. Y una de esas libertades es la libertad a elegir (en este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...).
Uau, Rafa, estas muy confundido. Free/libre no se refiere a la libertad de elegir nada. Es la libertad que se le da al usuario de inspeccionar, modificar y distribuir el codigo fuente alterado.
Sí, las 3 libertades que te otorga/ofrece/garantiza la licencia GPL. Ya la conozco, llevo con Linux desde 1995 ;) Aunque no esté implícito en la licencia GPL, muchos de los que empezamos (hace mucho tiempo) en el mundillo FLOSS, fue por la posibilidad (libertad) de elegir. Te pongo un caso concreto. SUSE fué la primera distro en dar soporte oficial a XFS, JFS y resierfs, mucho antes que cualquier otra distro (ahora que lo pienso, no sé si Slackware tbn ofrecía soporte para otros fs) y eso a la gente le encantaba: podían elegir el sistema de ficheros en función de los datos que iba a almacenar (rendimiento, journaling, ...). Esto es un ejemplo concreto relacionado con sistemas de ficheros. En este caso concreto que yo he expuesto (una actualización hizo que mi equipo no se pudiera utilizar), si quiero rollback, la única opción que tengo es usar btrfs o LVM. No hay otra opción. OJO ! No digo que sea malo, no estoy señalando con dedo acusador. Sólo digo que sería interesante/útil tener la opción de rollback dentro de zypper ... me habría ahorrado mucho tiempo (y hubiese evitado este hilo xD) Que la opción de snapshots de btrfs es mucho más completa ... sí, es cierto ... pero no necesito todo lo que ofrece btrfs (caso particular mío), como siempre, pongo lo de MHO. Hablo de mi caso concreto. Como he dicho en el correo anterior: no estoy en contra de btrfs y lo usaré en el trabajo en el momento que se me convenzca que su equivalente a Z1, Z2 y Z3 es estable y "production ready". Y, creeme, tienes cientos de Exabytes de usuarios de Lustre y BeeGFS que lo usarían también con tal de quitarse el ZFS que ponen por debajo. Así que vuelvo a lanzar la pregunta a SUSE: ¿considera SUSE que el equivalente a RAID 5 y 6 de btrfs está listo para producción? ¿Tiene SUSE clientes usándolo? ¿En qué entornos lo están usando los clientes? ...
En ese sentido, zypper esta en github bajo GPLv2. Es C++, y ya hay gente ejercitando la libertad que ofrece FLOSS:
Ya, ya sé que es FLOSS, igual que YaST ;) MHO, Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org