EDICIóN GENERAL
26 meneos
422 clics

Una comparación técnica entre snaps y debs. (ENG)

La introducción del formato de aplicación autónomo, como los snaps, ha creado un cambio de paradigma en la forma en que las aplicaciones de Linux se crean, distribuyen y consumen. En este artículo, nos gustaría ofrecerle una descripción general de algunas de las principales diferencias entre los dos formatos de archivo y cómo pueden adaptarse mejor a sus necesidades.

| etiquetas: snap , deb , paquetería , linux , gnu
#4 si, eso no lo dicen en la comparación y sin embargo, dice que no se verifica casi nunca la firma de los paquetes Debían, cuando en realidad se verifica siempre (a no ser que te descargues el paquete deb a mano y lo instales a mano, cosa que no suele ocurrir) aunque la firma de los paquetes SNAP es casi peor que los repositorios Debían que tienen una firma verificada y no una firma arbitraria por cada paquete, o que las actualizaciones son malas (cuando eso tampoco es así). Y así mil cosas más....
Vamos que casi diria que esta comparación es publicidad engañosa y amarillista de los paquetes SNAP.
Vaya, no me esperaba que snapcraft apueste porque el formato snap es mucho mejor que el formato deb. Pero creo que se han sobrado con cosas que no son ciertas.
#1 MI aptitude solo me lo quitaran de mis manos frías y muertas.
#1 Y tanto.

En Phoronix, explican que esos formatos (fltpak, snap) degradan el rendimiento del sistema por la duplicidad de bibliotecas cargadas en memoria.

Básicamente que como cada aplicación tiene cargadas sus bibliotecas, no se hace un uso adecuado de la caché del procesador.
#4 ¿sucede igual con docker en el server?
#8 Pues claro
Infinitamente mejor los programas empaquetados en .deb linkados dinamicamente de toda la vida, y donde actualizando una librería se actualizan todos los programas que la usan.
Para programas de fuera de distribucion ya existe el empaquetado appimage que cumple perfectamente, y no necesita las mierdas que pide snap como tener un servicio activo en memoria.
Sin animo de polemizar, me parece algo corto el post para ser técnico. ¿Y como que los .debs no van firmados? :shit:
Donde se ponga un arbol de ports, que se quiten todas las tonterías. Emerge rulez, pacman rulez, bsd ports rulez, etc. Y si no os gusta, os jodéis y aprendéis a tunear el /etc/make.conf y así de paso leéis la página man del GCC :-P

Además, los "snaps" esos no tienen ni comprobación de alteración de código binario mediante firmas, certificados u cosa parecida, por lo que más que un sistema de distribución de binarios lo que parece es un sistema de distribución de malware. Los debs por lo menos usaban firmas GPG. Resumiendo: los snaps son el systemd de los paquetes.

Venga, empezad a odiadme l-users ubunteros :troll:
#7 puto systemd. ¿Qué necesidad había?
#7 #10 veo opiniones en contra de systemd pero la verdad desconozco el motivo. A mi me resulta bastante cómodo de usar con systemctl restart xxxx o similar.
Que tiene de malo y qué otras opciones hay y en qué distribuciones? lo digo por si me convencéis para el cambio (ahora uso Arch con systemd)
#16 Pues se diría que parece que no tienes mucha experiencia con Arch, porque cualquier arch-user sabe que en la wiki esta TODO (sobretodo cuestiones como sysrc vs systemd, archivos de conf, etc). No pasa nada compi, no te ralles y sigue mi consejo: empieza por aquí: wiki.archlinux.org/index.php/Systemd ;-D
#17 tengo mucha experiencia con Arch (busca mi nick en sus foros y mira la fecha de mi registro). Pero precisamente lo que no quiero es investigar, sino un resumen rapidito, ese enlace es un poco largo para mi gusto

Si me da por investigar no pregunto, ya me apaño yo como buen linuxero ;)
#18 Es que es mu largo de explicar, no se puede hacer un resumen en un comentario. Es algo que tienes que mirar tú si quieres enterarte de la movida y eso implica navegar la wiki de Arch y tener ganas de leer. No te puedo resumir el "man 1 systemd" en Arch y el "man 1 init" en un *BSD o en una debian Woody, tendría que empezar por el doble fork () del proceso init (pid=1) y terminar por los putos logs binarios del journalctl :-P
#7 Por alusiones(l-user ubuntero), y habiendo sido gentooza varios años(lo abandone por tener que esperar un día a actualizar todo el sistema como hubiera algo que implicara entornos gráficos, los procesadores daban lo que daban en aquel entonces) ... Sabes que capacidad de espanto a futuros usuarios has generado en ese comentario? Tu déjales que prueben las drogan blandas, que ya habrá tiempo para las duras :troll:

Ya volviendo a la noticia.. Aha, nos venden que un sistema que calca la distribución de software en windows/OSx es mejor...
#12 Déjalos que se asusten, así los demás cobraremos mejores salarios por el plus de pr0 (o de BOFH) de la nómina :troll:
La foto es 100% random?
Por qué no comparan snap con jpg ? También son dos formatos de archivos.

Ya puestos...
comentarios cerrados

menéame