145 meneos
2509 clics
Ubuntu tiende la mano a Linux Mint para hablar sobre Snap
La polémica en torno a Snap suma una nuevo capítulo, después de que Linux Mint dijese basta de manera rotunda. Ahora responde Ubuntu y lo hace abriendo la puerta del diálogo, pero también aportando algunos datos de interés. La respuesta de Ubuntu parece coherente y aporta un dato interesante: «Linux Mint tiene el mayor número de usuarios en todas las distribuciones compatibles».
|
comentarios cerrados
En el mundo de Linux para servidores parece que se ponen más de acuerdo, quizá porque hay dinero de por medio, pero en el mundo desktop siguen con las mismas batallitas dentro de la comunidad que hace 15 años y ya empiezan a aburrir a los usuarios.
Yo lo odio porque en mi local instalé un entorno de desarrollo web procedente de Debian que tenía un Chromium headless para convertir páginas web en PDF. Pues bien, una aplicación dentro de Snap no puede escribir fuera de ciertos directorios y me petaba muy fuerte la aplicación web y fue un infierno encontrar el fallo.
Link: askubuntu.com/questions/1184357/why-cant-chromium-suddenly-access-any-
Una vez que lo usas, las cosas que tienes instaladas se dividen en dos: Las que has instalado con APT y las que has instalado con ese sistema. A partir de ese momento, "dpkg -l" ya no te da una lista de todo lo que tienes instalado (como pasa también cuando haces "make install").
Las ventajas de saber que todo está bajo el control de APT empiezan a desaparecer.
Tiene sus desventajas y sus ventajas... La genteo "odia" porque los paquetes están aún un poco verdes y los permisos y demás fallan mucho pero si el paquete está bien hecho no dan mayor problema. Lo único que ya no los controlas con apt y como cada paquete instala todas las dependencias abultan más ...
Si te refieres al pasado de Gimp multiventana... ten en cuenta que Gimp fue disenyado con escritorios virtuales en mente, y no con escritorios limitados como los de Windows y Mac.
Total, las actualizaciones son automaticas con slackpkg upgrade+sboupgrade.
Con los repos de AlienBob tienes una lista ingente de software de Slackbuilds ya precompilados y donde instalarlo es sencillico, solo es meter Slackpkgplus y editar la configuracion. La ventaja es que los paquetes son vanilla, sin parchear ni hostias. Todo puro. Y sin SystemD.
Si, los SlackBuilds compilados de AlienBob piden dependencias, pero te las ponen en su web por paquete asi que solo es "slackpkg install loquesea bla bla blo" y a tirar millas.
Para el resto: slackbuilds.org/ y pink-mist.github.io/sbotools/
Lioso? Depende, aunque cierto es que instalar Virt-Manager con Spice
esera pesadillesco, hoy ya sbotools entiende todo.slackbuilds.org/repository/14.2/system/virt-manager/
Si usas windows, y buscas en tu disco duro archivos llamados msvcr*.dll -por ejemplo- verás que tienes docenas de archivos con el mismo nombre: el .dll es una libreria y cada programa lleva las suyas. Esto tiene la parte positiva de que cada programa lleva las suyas (y no hay problemas de incompatibilidad de versiones) y tiene la parte negativa que a veces tienes 20, 30 o 40.. o 100 copias de cada libreria en el disco duro (y hay muchas comunes). Cuando tienes muchos programas instalados, a veces se llega al absurdo.
Si usas linux, solo tienes una libreria de cada, aunque a veces traiga algun problema de incompatibilidad de versiones.
Snap pretende traer el sistema de windows (linkados estáticos) a linux (linkados dinámicos) y la gente no quiere, porque vino a linux huyendo de windows
Está bien para instalar algún programa de pago concreto, y que no de problemas de compatibilidades, pero si, que venga todo asi es un horror.
Te hace un jail (jaula) donde instala todo, pero no tienes acceso directo a eso, por lo que, por ejemplo, si tienes el /home en otro sistema, pues te jodes. Suele ser más lento, más "oculto" y menos visible, tiene su propio buscardor de programas, que es una mierda... es el típico:
imgs.xkcd.com/comics/standards.png
Lo utilicé unas horas (por programas que sólo estaan ahí) hasta que me cansé y lo desinstalé y a tirar con wine para lo que necesitaba...
Reglamente digo sin entender porque son necesarios snaps y flatpacks. Apt , yum, dnf tienen resuelto el chino gestionar dependencias de hace mucho.
No es funcional. Es un absurdo esperar que los usuarios normales vayan a hacer eso (y francamente, yo hace anhos que no lo hago y no estoy dispuesto a volver a eso).
Si el sistema no funciona con una orde única, entonces no es adecuado para escritorio.
Si necesitas un software que no está en tu distribución, siempre puedes compilarlo o descargarlo a pelo y ponerlo en algún lado (y tener suerte con las dependencias, claro) o instalar un nuevo repositorio de aplicaciones externo. Todo esto tiene implicaciones en la seguridad y estabilidad de tu distro, lo usas bajo tu propio riesgo.
Esto sería lo que hace un .deb o un .rpm a grandes rasgos.
Snap es un sistema de paquetes tipo android (.apk); aunque puede ser la distro quien los empaquete, la gracia está en que cualquiera puede hacer un paquete y al meterse en un entorno aislado y poder controlar qué permisos y qué accesos puede tener a los recursos del sistema, se supone que es seguro tenerlas (se supone, mira a android :P). Aunque la distribución de snaps está centralizada en una tienda (la tienda de software de ubuntu, snapcraft), puedes descargar snaps de cualquier lado. La ventaja es que puedes instalar software sin preocuparte de las dependencias y sabiendo que va a funcionar software viejuno o más moderno que tu distro porque cada aplicación lleva su entorno de ejecución.
El problema es cómo está haciendo ubuntu para implantar snap como herramienta de facto de empaquetado de aplicaciones (ya sabes que hay otras alternativas, como appimage o flatpak, cada una con sus ventajas y sus desventajas). Por lo pronto, al contrario que otras distros donde el centro de software está conectado con el repositorio (o sea, con .debs o .rpms) está conectado con snapcraft, con lo que todo lo que instales más allá del sistema base son snaps (con el aumento de consumo de recursos y la disminución en la respuesta del sistema, haciendo la distro menos adecuada para equipos más modestos).
Y de lo que se queja específicamente linux mint: han convertido al menos algunos paquetes .deb en falsos paquetes que simplemente se encargan de descargar el snap correspondiente, de manera que las personas que no quieran trabajar con snaps y se estuvieran instalando las aplicaciones a pelo en lugar de desde el centro de software/tienda de ubuntu estarían instalándose snaps igualmente. Ubuntu se escuda en decir que lo hacen por cuestiones de seguridad, para proteger a la gente, Mint opina que lo hacen adrede y que están haciendo daño a las distros basadas en ubuntu que no quieren seguir sus pasos en torno a que todas las aplicaciones se instalen como snaps.
Snap de por si no creo que sea odiado (más allá de si es la mejor solución técnica al problema del empaquetado y los piques con otras opciones como appimage o flatpak), sino la forma de obligarte a usarlo y la forma de intentar que otras distros tengan que hacerlo también (recordemos que Linux Mint tiene tantos usuarios o más que ubuntu, y la misma ubuntu dice que más de la mitad de paquetes snap descargados de la tienda e instalados son por parte de usuarios de Mint).
También son muy útiles para probar betas o nuevas versiones de una aplicación dada, teniendo ambas coexistiendo y pudiendo ejecutarse a la vez para poder compararlas y demás (que no es que no se pueda hacer normalmente, pero es un coñazo)
Muy útil para escenarios concretos. Nunca como sistema de paquetes general
Los tres se.cimpñementan.
Gimp tiene mala usabilidad y no por las multiventanas sino porque no puedes hacer, p ej, algo tan simple como rotar, redimensionar y mover la imagen sin tener que estar cambiando entre las herramientas de rotar, redimensionar y mover.
Lo que no sé es si existe para snapd pero me extrañaría que no.
Cc #33
Yo no uso esa herramienta. Solo hago foto manipulaciones y recortes.
Cuando tienes que administrar decenas o cientos de máquinas lo de hacer make install no mola nada.
Edit: El snap lleva su propio registro (snap list), pero al final es como tener paquetes deb y paquetes rpm en la misma máquina, una especie de "disidencia"...
Por otro lado nunca aprendí a hacer chroot bien. No he encontrado ni un solo tutorial en español que empiece de 0 absoluto de ese tema.
Y con los ports para lo que no se puede distribuir en paquetes (literalmente dos o tres, plan Eduke32/Xephem, poca cosa), es darle 200 vueltas a APT y su gestion.
La gente no es consciente de los entornos reproducibles facilmente sin lios de dependencias raras al instalar, cosa que me ha pasado con Mageia y dependencias circulares.
Slack me encataba por estabilidad y que no había carpetas raras en la raiz...pero eso de tener que toquetear cosas me cansa.
- mkdir target
- desempaquetas el "rootfs" de tu distro en target
- mount --bind /dev $PWD/target/dev
- mount --bind /proc $PWD/target/proc
- mount --bind /sys $PWD/target/sys
- mount -bind /dev/pts $PWD/target/pts
- cp /etc/resolv.conf $PWD/target/etc/resolv.conf
- cp /etc/group $PWD/target/etc/group
- chroot $PWD/target /bin/sh -l
Con las SSD hoy sboupgrade en un Celeron dual core chatarrer me tarda 40 minutos.
Lo mejor es tener TODO el sistema, de arriba a abajo, con un solo sistema de paquetes. Asi TODO el sistema se puede actualizar de una tirada.
Recuerdo un servidor donde por alguna razón alguien instaló a saber cómo un python3 en un sistema python2, sobreescribiendo todo lo de esta versión. Las herramientas de gestión de paquetería iban sobre python2 y estaban tirando de python3 como runtime y evidentemente no funcionaban y no había forma de revertir los cambios (aparte de otros programas no tan vitales que sólo funcionaban en python2).
Recuerdo otro equipo donde por razones de poder tirar un programa que necesitaba lo último se instaló también una versión de gtk que rompía cosas hacia atrás, se podría decir que se quedaron sin aplicaciones gráficas (ni iba gdm, ni usando kdm como gestor de sesión luego iban las aplicaciones de gnome).
Con un flatpak o un snap o un appimage, lo peor que podría pasar es que la propia aplicación empaquetada no funcione (total o parcialmente o no vaya alguna funcionalidad o esté muy capada desde la configuración y no pueda acceder a algún recurso externo), nada de fastidiar al resto del sistema.
bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1849371
- Usuarios que no quieren hacer un mínimo esfuerzo para entender como mantener su sistema, de la misma manera que uno tiene un coche pero se despreocupa de llevarlo al mantenimiento o ponerle gasolina porque 'yo el coche lo quiero para conducir'.
- Desarrolladores superstar que, de la misma forma, solo se preocupan de su código, como si el resto del mundo no fuera con ellos. Otro producto de este pensamiento mágico son los contenedores en si, Docker y mas mierdas. Porque? a) realmente no solucionen problemas, solo lo aíslan, creando en si nuevos problemas y b) perpetúan una tendencia a ofuscar el software. Es mas difícil trincar dentro de un contenedor.
No quiero una informática de dos velocidades, y menos dentro del mundo del software libre. Para la infromatica cerril ya tenemos a Microsoft y Apple.
Ya mencionados, no, no creo que seguir el modelo de Apple o Microsoft para gestionar software sea la manera. Es un paso atrás en varios aspectos.
Yo llevo prácticamente desde que deje Gentoo con RHEL/CentOS/Fedora, en casa y profesionalmente y raramente tengo problemas. Y cuando los hay el sistema te dice que es lo que esta mal.
Otras ventajas para mí incluyen: usar software muy reciente o poder usar mucho software extraño compilado (AUR) que desde Ubuntu/Fedora no podría debido a que yo realmente no sé compilar. Un make install sin saber falla muchísimo (e incluso sabiendo) mientras que Yay no (o te ayudan a solucionarlo). (aur.archlinux.org/packages/qosmic/ )
En Manjaro también tengo acceso a flatpaks/snaps (creo que solo he instalado pycharm así) y a alien y debtap. Es decir tengo todo el software de las rpm/deb con posibilidad de poder usarlo y además tengo una herramienta que me permite compilar muchos paquetes extraños sin tener casi idea.
Las distros rpm/deb basan su éxito en tener mucho software precompilado y empaquetado. Arch/Manjaro no puede competir en eso por lo que coge paquetes de todos los sitios que puede.
Bueno, lamento el tocho. Un saludo grande.
"- Usuarios que no quieren hacer un mínimo esfuerzo para entender como mantener su sistema, de la misma manera que uno tiene un coche pero se despreocupa de llevarlo al mantenimiento o ponerle gasolina porque 'yo el coche lo quiero para conducir'."
Con un flatpak o snap o appimage se despreocupan igual, están aislados en un sandbox en mayor o menor medida, así que deberían ser lo suficientemente seguros (o incluso más que la instalación de cualquier software en tu distro, que tú puedes configurar mal y abrir huecos y problemas de seguridad que con un flatpak/snap/appimage no tendrías).
"Porque? a) realmente no solucionen problemas, solo lo aíslan, creando en si nuevos problemas y b) perpetúan una tendencia a ofuscar el software. Es mas difícil trincar dentro de un contenedor."
¿A qué te refieres que es más difícil trincar dentro de un contenedor? de hecho, sirven para eso, para aislarlo todo de lo demás y que no haya problemas con el resto del sistema y del software, debería ser una ventaja para todos. Cuanto menos "daño" hagan los superstar mejor, si se quedan en sus aplicaciones contenidas, menos problemas dan al resto.
No puedes obligar a todo el mundo a seguir el mismo modelo. Y flatpak/snap/appimage aportan más libertad sin afectar al sistema o al resto de aplicaciones sin convertir esto en un reino windows/mac es un paso positivo para todos.
Para mi tener una manera solida y madura para hacer una cosa, y que este suficientemente documentada como para que se pueda hacer cambios con facilidad, es la manera correcta.
Tener que recurrir a:
- varios comandos para sacar una lista unificada
- O una abstracción que me muestre esa lista
Es en ambos casos un atraso. Y si, aislar partes del sistema lo veo como un atraso a menos que sea para justificar un modelo de seguridad máxima.
Tener que repetir una librería X veces para X software corriendo en el sistema es una somera estupidez, que no hace mas que perpetuar un modelo de perdedores; como no sabemos como resolver algo, hacemos una agujero y ahora este es nuestro agujero donde estamos seguros, con nuestra librerías.
Esto nos lleva a que todo se vea como un micro-servicio, desmontando funcionalidades como comunicación hoste-to-host, paso de mensajes entre procesos, etc. Estamos convirtiendo el PC de escritorio a un modelo como los teléfonos móviles, donde todo acaba comunicándose con una API.
Simplemente no me gusta ese modelo. Se carga el buen trabajo hecho durante décadas en los sistemas operativos y entrega el poder a otra capa, donde se tienen que re-implementar muchas funciones, reinventar la rueda, introduciendo mas capas de abstracción para algo que a mi no me resultaba en absoluto un problema.
Así que no, no me gusta la solución, porque se que acabare teniendo que trabajar con un sistema de mierda para que un grupo de gente que no quiere dedicar dos minutos a arreglar algo, o leer como funciona lo que usan.
Ya esta, /rant off/
En todo caso, prefiero usar una version un tanto antigua, en pro de la estabilidad. La unica razon para usar algo a pelo seria muy extrema para mi. En muchos casos me os encuentro con pip o gem, y si se trata de algo mas ratito como algo de escritorio... en esa caso tal vez si que algunas distros siq ue lo tienen un poco mejor que otras.
Pero vaya, algo como esto:
gitlab.com/corectrl/corectrl
Cuesta tanto esto?
Como lo instalo:
dnf install corectrl
keybase 14 kB/s | 3.3 kB 00:00
Slack 709 B/s | 1.0 kB 00:01
Dependencies resolved.
...
...
Installed:
botan2-2.11.0-2.fc31.x86_64 corectrl-1.0.8-1.fc31.x86_64 qt5-qtcharts-5.13.2-1.fc31.x86_64 vulkan-tools-1.2.131.1-1.fc31.x86_64
Complete!
menos de 30 segundos!
Cual es el problema, para que cojones quiero un flatpack o un snap o tros mierdos?
Y luego hay gente que tiene burradas de espacio y quieren aislar procesos. Yo ni una cosa. Ni I la otra.
Por eso flatpak usa el concepto de runtimes: descargas un runtime, este se actualiza de manera independiente (parches de seguridad, para no romper compatibildiad, claro) y es válido para varias apps. Se evita la excesiva duplicación, garantiza que el runtime es seguro y está todo lo mantenido y parcheado posible y no haces responsable al empaquetador de la aplicación de ese mantenimiento "externo" (tener que actualizar toda la app porque se ha descubierto un parche de seguridad en una librería externa y esas cosas).
"Estamos convirtiendo el PC de escritorio a un modelo como los teléfonos móviles, donde todo acaba comunicándose con una API."
En un pc todo acaba comunicándose con una API. ¿Qué piensas que son las llamadas al sistema? ¿qué piensas que es un protocolo como wayland? ¿qué crees que es usar librerías?. Nunca usas ni deberías usar directamente los recursos, para eso está el sistema operativo. Desde que has empezado a usar un sistema multiproceso y multiusuario ya has tenido que delegar la gestión en un SO. En flatpak al menos, el uso de portales (o sea, la forma de acceder desde las aplicaciones dentro del flatpak a los recursos del sistema) debería ser transparente (es GTK o QT quien lo gestiona, tú sigues programando tus aplicaciones igual que antes y del mismo modo que el soporte Wayland, mientras uses correctamente las APIs). Desde el punto de vista del desarrollador, no hay que hacer nada (si usas gnome builder, por ejemplo, te hace el empaquetado directamente, sólo tendrás que configurar los permisos que pide la aplicación al sistema y alguna cosa más).
"Using portals in apps
The good news is that most of these will just work transparently in GTK+ applications, since GTK+ and GLib have suitable APIs that can be made to use the portals without any changes required from the sandboxed application. This support is already in place in the master branches; and will be in the 3.22 releases. We are working on a similar level of support for qt/KDE."
Desconozco cómo hace esto snap (appimage si mete todo dentro de un solo fichero, librerías y demás, aunque esté chrootado no es lo mismo).