Hola :)
On Tue, Jul 21, 2020 at 2:36 PM Ancor Gonzalez Sosa
On 7/21/20 1:27 PM, Rafa Griman wrote:
Hola :)
[...]
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. [...]
En la práctica, eso es básicamente cierto. Pero mi comentario no trataba de apuntar tanto a cuáles son las consecuencias en la práctica, sino a la supuesta intencionalidad que la frase original atribuía a los desarrolladores de zypper. Como ya Carlos aclaró, lo decía con cierta sorna. ;-)
Ya, ya :)
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.
No exactamente. Zypper es un proyecto de software libre. Que SUSE no le pague a alguien de su plantilla para desarrollar una característica concreta, no significa que SUSE esté decidiendo que esa característica no se implemente. Simplemente está decidiendo no pagarla de su bolsillo.
Por eso usé las doble comillas ;) Y estoy 100% de acuerdo, SUSE dice que no lo va a pagar de su bolsillo y, como digo, tiene todo el derecho a opinar y actuar de esa manera. La estrategia de SUSE es basarse en btrfs-LVM y sus snapshots.
Sigo pensando que no debe ser una tarea hercúlea desarrollarlo y sería
No tengo ni idea de cómo de difícil será de implementar, pero sin duda implica dedicar ciertos recursos: horas de trabajo de los desarrolladores, pruebas y verificación, esfuerzo de documentación, dificultar el mantenimiento de zypper para el futuro al tener más cosas que tener en cuenta.... Aunque no llegue a la categoría de hercúleo, si que te aseguro que hay una cierta tendencia a subestimar el esfuerzo y las consecuencias de estas cosas.
Tranquilo, que no subestimo el esfuerzo (económico, Humano y en tiempo) que puede suponer un desarrollo. Como mencioné antes, llevo desde 1995 en el mundillo FLOSS y he trabajado en alguna empresa de FLOSS y desde hace 15 años me dedico a HPC así que sé lo que supone desarrollar, optimizar, depurar, validar, ... Y eso que no soy yo quien desarrolla el SW 0;) Cuando dije que no me parece hercúleo, a lo que me refería es que ya está YUM como ejemplo, rpm tiene alguna opción útil en la que se puede basar zypper, ... Es decir, no es empezar completamente desde 0 y todo lo que ello supone: diseño, análisis, ... Y no, no propongo "copiar y pegar" ;)
Los recursos de SUSE son más limitados de lo que algunos puedan pensar. Así que el uso de esos recursos a menudo se concentra en cosas distintas de las que nos gustaría a algunos usuarios.
Me hago una idea de los recursos que tiene SUSE, creeme ;) Y estoy de acuerdo en que hay que destinar esos recursos (económicos, Humanos y de tiempo) hacia la visión, misión y estrategia de SUSE. Por eso mismo digo que es MHO y que sería útil. En ningún momento he dicho que SUSE _DEBA_ implementar rollback en zypper 0;)
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".
Cuestión de usar esos argumentos para intentar convencer a:
a) alguien que se lie la manta a la cabeza y lo implemente
Claro, por eso no he dicho que SUSE deba ser la que lo implemente ni que dba implementarse, sino que sería útil. Y, por cierto, sé que SUSE es mucho (o era) mucho más abierta a colaboraciones/aportaciones de externos (particulares o empresas) que Red Hat. Por eso, por ejemplo, SUSE incluyó y soportó XFS (y Ceph) antes que Red Hat ... muuucho antes que Red Hat ... Pena que Red Hat contratase a todos los desarrolladores de XFS y comprase InkTank ...
b) los desarrolladores de SUSE (o sus jefes) para que lo hagan como parte de su trabajo en la empresa.
SUSE tiene cosas más importantes que hacer que implementar rollback, sinceramente. Como dicen los gringos, simplemente era "wishful thinking". Por eso, cuando he hablado con gente de SUSE ... ni lo he sacado ;)
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
Al igual que apuntó Alberto, no creo que ese sea el significado de "libertad" en el contexto del software libre. En absoluto.
Ya, lo dije en un correo anterior y Carlos también. En el "manifiesto" inicial de Stallman no viene implícito (ni en la licencia GPL, LGPL o cualquier otra considerada FLOSS) ni en ningún otro documento. Me expresé mal 0:) A lo que me refiero es que esas 3 libertades dan lugar indirectamente a la libertad de elegir ... ya que la libertad de hacer un fork puede dar lugar a una segunda alternativa. vi, vim, nvi, ... vienen a la mente como ejemplos muy simplones o que GNOME se empezase a desarrollar porque Qt no era GPL o que exista systemd porque SystemV init estaba anticuado y carecía de algunas características ... ¿Significa eso que SUSE (u otra distro) _DEBA_ ofrecer _TODAS_ las alternativas? No. Y, una vez más, esto es MHO ... sería útil/interesante que incluyese algunas (wishful thinking). Obviamente, eso es decisión de SUSE basado en sus prioridades (visión, misión, estrategia, inversores, clientes, ...). Simplemente estaba dando mi opinión, que se puede ignorar y todos tan contentos ;)
este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...). Y, como dije en un correo anterior: no espero tener TODAS las opciones, pero por lo menos más de una ... aka cierta flexibilidad.
Asumiendo que FLOSS significa flexibilidad (que ya digo que discrepo). Lo cierto es que sí tienes cierta flexibilidad:
a) usar openSUSE con btrfs + snapper + zypper b) usar openSUSE con LVM + snapper + zypper c) usar openSUSE con otro sistema de archivos + dnf (yum)
Exacto, es lo mismo que he dicho antes. Ya he comentado que LVM supone una capa adicional si tienes que entrar a recuperar datos (y lo he tenido que hacer muchas veces). En cuanto a las ventajas que tiene LVM: - agrandar espacio en disco: los únicos sistemas de almacenamiento que he tenido que "agrandar" han sido BeeGFS, Lustre, GPFS y ZFS ... Ninguno de ellos usa LVM (bueno, ZFS tiene un gestor de volúmenes intrínseco). El disco local es para un OS "pelao" que "no crece" y si falla, metes otro y reinstalas. La otra utilidad del disco local es scratch local. - snapshots: no se suelen hacer snapshots de esos sistemas de ficheros ;) Para $HOME, como suele estar en ZFS o NetApp ... te lo hacen ellos. Así que los snapshots de LVM no los necesito, el disco local es para un OS "pelao". - mirroring (~RAID1) para el OS del nodo: no lo necesito, prefiero dedicar ese segundo disco a scratch local. Si el disco del OS casca, lo cambio, reinstalo y a seguir "moliendo números" Si hablas con gente que gestiona SAP, Oracle, PostgreSQL, ... es otra historia. En mi trabajo anterior tenía que gestionar varios PostgreSQL muy críticos (para la OMS), obviamente, ahí sí que propongo RAID1 (ó 10, según el crecimiento de la BBD), snapshots, múltiples copias, backups, redundancia, HA, load balancing y copias en papel si hace falta xD
d) usar una distribución que esté más alineada con tu caso de uso
Por desgracia ... Digo por desgracia porque la distro de SUSE me gusta mucho y llevo muuuuuucho tiempo usándola. Por desgracia, tengo que gestionar clusters con CentOS y también he tenido que gestionarlos con Ubuntu. No odio esas distros, pero sinceramente, prefiero SUSE. NOTA: los clústers llevan CentOS/Ubuntu por otras razones, no porque no pueda hacer rollback ... no vaya a haber malas interpretaciones ;) En mi casa también estoy empezando a migrar algunos equipos a otras distros. ¿Significa eso que odio SUSE o que la detesto o que me vaya a dar de baja de las listas? No. ¿Voy a quitar SUSE de todos mis equipos en casa? No. El de mi mujer seguirá con SUSE por la facilidad de uso, YaST, ... En ese caso, veo útil NetworkManager y systemd y todas esas cosas "automatizadas", "plug'n'pray", ... Pero para mis equipos personales no necesito esas cosa así que buscaré alguna distro que me permita elegir. En el portátil del trabajo, pues sí seguiré con Tumbleweed lo más seguro. BTW, una de mis cuñadas está muy contenta con SUSE desde el 2007 (IIRC) y no la voy a migrar a otra distro ;) Y mi suegra también.
Razones (técnicas) por las que digo que no quiero usar btrfs o LVM (esto son experiencias personales, YMMV): [...]
Sinceramente, yo tampoco duermo 100% tranquilo con btrfs en un sistema en producción. Por otro lado, de LVM sí que me fío.
Entonces comprenderás mi situación, especialmente cuando hablamos de datos MUY sensibles. Como tú, también me fío de LVM (lleva muchos años y está muy probado), pero no me vale para lo que yo hago ... bueno, para lo que hacen mis usuarios. HTH y 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